I also second this suggestion, but given correct DNSSEC implementation—especially for a large hosting company such as yourself is long, complicated, and fraught with danger not only for yourselves but also your customers (it's incredibly easy to botch key rollover in a manner that breaks your domain—just ask NASA—or compromises security), I'd like to make an additional suggestion.
First, and as a matter of priority, provide a method that allows DS records1 to get from the registrant (DreamHost customer) to the registry in a secure fashion. E.g. have a button next to a domain registration (mark it 'advanced', and include the usual "Warning! Danger, Will Robinson!" disclaimers) that allows a customer to supply their own DS record data, which you then securely transmit to the appropriate registry. This will allow customers with their own DNSSEC implementations to secure DreamHost-registered domains.
A full DNSSEC implementation for the DreamHost DNS service is essential, IMHO, but allowing customers to provide their own DS records should be relatively trivial and would get the early adopters—like me—off your back.
Forwarding DS records to the registry is the only thing needed for customers to run their own DNSSEC; no DreamHost-registred domain can implement DNSSEC (without look-aside validation) without this.
DS record contains a key 'fingerprint', which facilitates the chain of trust in DNSSEC. The root (.) zone contains a DS record for .net, which verify's the key in .net's DNSKEY record; .net contains a DS record (not yet!) for calrion.net, which verify's the key in calrion.net's DNSKEY record. More info at Wikipedia.