I think so.
I create specific view model classes that represent the information exchange between browser and server. If the model state is valid, then I copy the values or call the domain methods with those values (that's what the Models folder is for). I never put MVC specific attributes on my domain entities.
Rule of thumb, I keep my entities in a separate assembly, that knows nothing about MVC.
Watch out with expose domain entities in your MVC action methods... the model binder could do you a bad joke :D If for example, you have a class "Account", with a property "IsAdmin" and you expose this entity in a registration form, the user could try to pass an arbitrary "IsAdmin=true" parameter in the GET string or in the POST payload, and the MVC model binder will set that property in your model... and your code will probably save that information in the database.
Therefore, I think is very important to keep attention on the view models.
I know that with all this "dynamic" stuff like the ViewBag and let your own LINQ entities be parameters in the action methods everything becomes very easy to do... but we shouldn't overlook security, and to enforce security we have to be sure that only the information we want can arrive to our domain.
Cheers.