Single or multiple non-clustered indexes when pairing with a composite primary key
This is a strange one as [UserId] [int] IDENTITY(1,1) NOT NULL is unique.     

There could be a case to use [UserId] alone as the PK.  You will get less fragmentation compared to a composite clustered index TenantId, UserId.

I get you plan to use TenantId, UserId in all queries but you don't need to.  UserID will uniquely identify each user.  

If you have reports by TenantId you can include that in the tables and put a non-clustered index on it.  

As far as email I would just put a non-clustered unique index on it. You can include the other fields if you like but it is just picking up data from a single row so it is not really necessary.  Right now there is nothing to prevent duplicate email.

Could argue repeating TenantId in all tables is not 3NF as it can be derived from  UserId.

I personally would not repeat TenantId and have a view for each table that brings it in. I get you don't want to do it that way but it is still my answer. 

select t.*, u.tenant 
  from table t 
  join [user] u 
    on u.userid = t.userid  


User is not a good name for a table as it is a keyword.