Does it violate MVC in the strict sense, yeah, probably. Are there times when there's no harm in violating that? Sure. However, there are mechanisms to help you out and keep the concerns separate.
You can use your persisted domain objects in the views and validate against them, but when your view starts getting complicated, ViewModels become a necessity. For dead simple domain models or view-only views (not edits/creates), I'll sometimes fudge a bit and send them into the view as part of a composite object:
public MyDomainModel DomainObj;
public int OtherViewInfo;
However, for create and edit scenarios, ViewModels are far better. They allow you total control over the data being sent to the view and from the view.
If you are using EF 4.1 and CodeFirst, then yes, you'll end up with some duplication of attributes and properties between the domain and the ViewModel. This is unavoidable but gives you the flexibility of doing different validations specific to the view.
I've found it useful to have one extra layer of protection in the controller when actually saving the domain object in case I missed some validation in the view:
public class MyController : Controller
public ActionResult Edit(int id, MyViewModel model)
...Do stuff, check ModelState.IsValid...
catch (DbEntityValidationException dbEx)
// Catch any validation errors on the domain that weren't duplicated
// in the viewmodel
The next question to ask is how you map between the domain model and the ViewModel. There are a number of strategies and tools out there - AutoMapper and ValueInjecter (yes, spelled wrong). Personally, I've been using ValueInjecter although if you setup a mapping layer, you can try both. I've found that neither will work in 100% of cases, or at least I could figure out how to do what I needed, but a mapping service makes it easy to define custom left-to-right maps.