The more complex your system gets the more you will appreciate this division. However at the outset it just makes things more complex than the situation warrants and it's not clear if the system will ever grow large and complex enough to pay for this expense.
I recommend creating your domain model as a simple wrapper around the persistence model. This way if the whole system never gets complex you will retain 95% of simplicity and if it does get complex you're one refactoring away from making your "shallow" domain model into a full-blown domain model.
Likewise the outbound part of your view/DTO model can be a simple wrapper around the domain model. Inbound models will probably have to be their own classes with extra mapping. The latter might be a bit of a pain (in ASP.NET MVC, for example), however I suspect the pain is instructive - making your inbound DTO a copy of the entire object could be simply the wrong path altogether.