It is actually unclear whether DNSSEC is "what we want".
Right now, the certification of Web site, i.e. how a Web browser makes sure that it talks to the right site (when doing HTTPS) is done with digital certificates emitted from about a hundred of Root Certification Authorities. The root CA are entities who decided to go into the certificate issuance business, and what makes the hundred-or-so special is that they made a deal with Microsoft/Apple/Mozilla/Google so as to include their public key in the "trusted" store of every browser (or operating system). The deal includes a lot of legalistic gizmos and insurances.
Though often criticized for its opacity, public cost of individual certificates, and a few well-publicized blunders (lookup "Comodo" and "DigiNotar"), the PKI system tends to work, in an economic sense: commercial sites use them, and the CA are very rarely attacked (most attacks are about inducing the gullible user into ignoring the scary warnings that the browser emits when it finds something fishy with the certificates, rather than going to the trouble of subverting an existing CA). There is then relatively little incentive to change things (that is, there are a lot of people who would prefer another system for a variety of reasons, but, ultimately, these things are decided by those who pay for it).
DNSSEC is about taking these root CA out of the loop, and instead give the certification power to the people who maintain the DNS (the mapping from server names to IP addresses), in such a way that the two structures would be bound together: domain name inheritance (with the notion of "sub-domain") would be merged with PKI inheritance (with the notion of "intermediate CA").
It is unclear whether the new tenants would be more competent at the CA business than the previous; as I said, the actual system works already quite well, and certification is not the same craft as mapping names to addresses. It is also unclear whether such concentration of powers is really a good thing. For the big players, it would not change anything: Verisign-the-CA and Verisign-the-registrar are both Verisign.
On the technical side of things, DNSSEC offers easy distribution of certificates (aka "signed bindings of identities to public keys") through the DNS system, but that's not a problem which needed to be solved: right now, any SSL/TLS server happily sends his certificate chain as part of the initial handshake, and it works well.
Thus, given the uncertainties about the goodness of DNSSEC, and the lack of flagrant issues with the existing PKI, it is no wonder that deployment is deemed non-urgent by the big companies. Let's get IPv6 working first.
As indicated by the comments below, DNSSEC has some value as itself for authenticating DNS information, which blocks DNS poisoning. DNS poisoning is the easy way to do a Man-in-the-Middle attack, but it would be wrong to believe that this solves MiTM issues; it just makes things a bit harder for the attacker (e.g. the attacker must use a WiFI-pineapple instead of simply abusing a hole in an existing WiFi hotspot). Getting guarantees about the mapping of a name to a given IP address does not get you far if you cannot know whether a given packet really comes from the IP address which is written in its header.
Either way, it does not provide much added value to the big servers, and that's sufficient to explain their reluctance.
(DNSSEC has military value, though: by preventing DNS poisoning, it helps in defending against big denial-of-service attacks that could be part of some global electronic warfare. I expect DNSSEC to be supported by governments, not by big companies -- but the days or ARPANET are long gone, and the Internet is the territory of private ventures nowadays.)