No, deadlock priority and isolation level are not defined at the DDL level but rather at the session level when the T-SQL command is executed. The above SET statements, the way you're using them, would not effect the behavior of the view you're creating. If users are selecting from a views, then they will need to supply the SET statements prior to the SELECT statement like so.
SET DEADLOCK_PRIORITY LOW;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT a, b, c FROM MyView WHERE z = 123;
It is also possible to enable READ UNCOMMITTED using the NOLOCK query hint like so:
SELECT a, b, c FROM MyTable (NOLOCK);
Alternately, you can contain the SET and SELECT statements within a stored procedure, and then the users simply execute the stored procedure.
I'm not that familiar with usage of SQL Server's Resource Governor, but my understanding is that it would involves pre-allocating resource pools, essentially reserving CPU and memory capacity, for use by these specific ad-hoc workloads. If you're trying to manage resources on a high-volume transaction server with limited resources to work with, this might not be manageable.
For your needs in this scenario, you might want to consider something like summary tables that are refreshed on a scheduled job that minimizes the frequency of the querying while still keeping the data fresh enough for the needs of the users. For example, I've retrofitted daily reports so they would feed from summary tables populated on a nightly schedule. Once done, the users can fire off that report 1,000 times with minimal impact, and the data is always consistent because it's static. As an added benefit, if you key your data using something like a ReportDate column, and retain the summary data from one day to the next, then it provides historical reporting when needed. This could be the first baby step in a more long range plan for implementing something like a reporting data mart.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho