This is the pattern my team uses for development using ASP.NET MVC and WCF, where your business/database dto maps to an entity framework class, your service dto maps to a POCO class/DataContract passed into/out of the WCF service and your UI dto maps to an MVC model.
While this might seem redundant, rarely do the needs of each layer lend themselves to a design where all three dto's in a stack have the same properties. One example where they tend to be different is in foreign keys into lookup tables. In the database layer, this will be represented by an int, while in the service layer, this will be better modeled as an enum, so as to impose type safety, and lastly, in the ui, said field will be converted into a localized string for display to the user.
In regards to your fear about over architecting, there is something to be said about keeping things simple. The forces that would drive me to use this pattern are that I have a need to deploy my application layer independently of my ui or simply that I work on a team with more than two developers. As your team grows, the likelihood that a team member will decide to bypass your business layer and go directly against the database goes up significantly. In doing so, they invariably defeat the purpose of any Aspect-Oriented Programming you have in place - I.e. stuff doesn't get logged or wrapped in transactions. Adding the extra layer and moving it to a separate server creates a clean separation of concerns, and, more importantly, enforces it. A one or two person team may be disciplined enough to avoid this, but, as you grow, it becomes a necessity rather quickly.
Hope that helps!