Totally get the benefit of DTOs for create / update, but it feels like an unnecessary step in read operations.
But what if you expose domain model to the view, and view changes some property? Are you 100% it will not be saved to db?
If you change one field in a db, do you have to change domain model and UI also?
Important concept is Persistence Ignorance, and how "far" are you willing to go with decoupling application layer from database and domain model. It really depends on your app, and there's no "one correct way of doing this".
Two things:
1.) ReSharper full solution analysis should bring those errors up. I wouldn't leave it on all the time, but flipping it on/off occasionally works wonders.
2.) Even without that, turn on the option to compile your views when you build. It's not super graceful (you'll have to fix one error at a time), but at least you won't accidentally ship a broken view!
Something else to consider is that maybe your MVC project is not your ONLY consumer of your application services. Now it makes a lot more sense to decouple things and maintain that extra layer.
Also the ViewModel is tightly bound to the view, if you want to change the view in clever ways that should not change the domain models.