Having struggled with this question before, I have in various instances gone with all three. In general, most of the opinions I’ve seen favor duplication in an MVC project, with a ViewModel constructed specifically for each view. In this manner the convention you’d use is something like UserDetailsViewModel and UserCreateViewModel. As you said, at that point AutoMapper or some other auto mapping tool would be used to convert from your domain objects to these flat ViewModels.
While I, too, don’t like repeating code, I also don’t like polluting my domain objects with validation or other view-specific attributes. Another advantage, though admittedly one almost nobody would ever have to contend with (regardless of what all the pros say), is that you can manipulate your domain objects in some ways without necessarily manipulating your ViewModels. I mention that because it’s commonly cited, not because it carries much weight for me.
Lastly, using a truly flat ViewModel makes for cleaner markup. When I’ve used composition, I’ve often made errors creating HTML elements with names that are something like User.Address.Street. A flat ViewModel reduces at least my likelihood of doing that (I know, I could always use HtmlHelper routines to create elements, but that’s not always feasible).
My recent projects have also pretty much required separate ViewModels these days anyway. They’ve all been NHibernate-based, and the use of proxies on NHibernate objects makes it not possible to use them directly for views.
Update – here’s a good article I’ve referred to in the past: http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx