Index to filter a view before joining the underlying tables
Could I through indexing alone influence SQL server to run this much faster.


Possibly.

There are all sorts of things you could try with indexing, including creating a filtered index to exclude the 95% of UserPasswordRequestHash entries that are null, expanding existing indexes to include more columns, or adjusting indexes so the chances of finding the first match is likely to occur earlier.

The query optimizer does not currently have the ability to explore separating the OR predicates into a UNION ALL, pushing each predicate below a local TOP (1) as a human query writer might naturally do.

It also has to make assumptions about the distribution of data to assess the chances of finding the first match, as mentioned above. In addition, there are all sorts of ways that the optimizer's calculations could be 'off', leading to it selecting the 'wrong' index strategy. Not being able to push index hints through a view also limits the opportunities for using a query hint via a plan guide, for example.

So, the best answer I can give from the information given is "possibly".

If you want a more concrete answer to your question, please supply complete DDL for the tables and indexes, and scripts for the existing statistics. Also, let us know how many logical processors, and how much memory, the instance is configured to use. I realize that is a lot of detail to provide, but a specific answer likely does depend on one or more of these details.