DNSSEC basically has all the problems of SSL registrars with almost no user-facing of the benefits - it's still a centralized system that could be overridden by a registrar hack or state level strong-arming, and very few end user systems support actually doing anything when DNSSEC signed records don't verify.
If you think users are confused by SSL warnings now, how the heck would they understand similar errors at the DNS resolver level?
Also, there's no-in flight encryption, so it offers no privacy benefit. It also aggravates DNS amplification attacks.
The better technology to look into if you're concerned about individual user rights and privacy is DNSCurve: http://dnscurve.org
It's not comparable to DNSSEC other than "It uses crypto with DNS" - they have entirely different goals, but the goals it solves are much more relevant to end users (privacy, forgery, etc.).
Personally, I'd recommend people run both techs, as there's no technical reason that makes them incompatible.
I have no idea how to solve the UI problems. We've had 15+ years of SSL and there's been almost no progress on that.
More on this topic can be found in this talk by djb.
Original video, complete with download links:
http://media.ccc.de/browse/congress/2010/27c3-4295-en-high_s...
This was djbs introduction to CurveCP, a project to replace TCP with an encrypted, authenticated, end-to-end solution that always gives you PFS. Unfortunately the Nacl code base (containing the CurveCP reference implementation) hasn't seen any community love that I know of, so the project seems to be kind of stillborn... although ZeroMQ recycled some of the ideas and cryptography in CurveZMQ