You may see something, but to some extent that depends on which DNS software you're running.
In particular, BIND sets the "DNSSEC OK" (aka
DO) bit on upstream queries even when not specifically asking for DNSSEC records or performing DNSSEC validation.
In those circumstances the root servers may send back additional DNSSEC records which may cause problems in the unlikely event that you've got broken network gear and/or misconfigured firewalls in the path.
Those problems mostly relate to packet size. Some kit doesn't like DNS UDP packets that exceed 512 bytes in length, either through buggy firmware or errorenous recommended configurations from the vendor. See my RFC 5625 for more details. Note though that most of the DNSSEC-related problems that I report on in that RFC relate to consumer class gear, and only in unusual configurations.
Do note that if your kit does have problems with large UDP packets, then the fallback is to use TCP. However some (misguided) security people configure their firewalls to disable outbound DNS over TCP, which breaks the fallback. See this IETF draft for more information about DNS over TCP.
By the way, to test your network's configuration for possible DNS quirks, I'd highly recommend the excellent Netalyzr website from ICSI at UC Berkeley.
To be clear, however, most DNS experts are not expecting significant issues because of the introduction of DNSSEC. Several TLDs (including .org and .se) have already been signed and the internet didn't collapse because of it.
The DURZ is a deliberate attempt to gradually phase in the larger responses that DNSSEC inevitably produces so that those rare sites that have network issues may resolve them before the entire root zone goes over to DNSSEC in the summer.