If the encryption software stores meta-data or other (unencrypted) signatures/magic-numbers, or verifiable structures, then these can be used for identification of course — but, since this gives the game away in a sense, you'll find that the better ones explicitly do not, e.g. from the Truecrypt volume format specification:
TrueCrypt volumes have no "signature" or ID strings. Until decrypted, they appear to consist solely of random data.
A TrueCrypt feature is plausible deniability, the intent being to make it impossible to prove the existence of an encrypted volume (or at least makes one's deniability of its existence believable).
I believe EDD relies on signatures for those formats which have identifiable signatures; heuristics, e.g. the presence of non-zero sectors outside a filesystem partition; and more recently named process/driver detection for those lacking signatures. This PDF paper covers some of the known signatures at the time (2005), including PGP (v9). This paper (PDF) is a more recent forensic analysis of OS X FileVault 2, which is interesting reading.
For practical purposes with software-only disk encryption implementations there may be unencrypted, easily identifiable code on the disk, e.g. in the case full-disk encryption with a boot-time password/key prompt. Identifying the bootstrap code may trivially identify the product.
Accurately identifying pseudo-random data is an impossible problem (though at least with encrypted disk volumes you should have a sufficiently large amount of data to make some statistical assertions about the randomness).
A robust encryption algorithm should have an output indistinguishable from random (regardless of identifying metadata in the actual output format), this is what TrueCrypt's plausible deniability relies on.
For performance reasons, disk encryption may not be as cryptographically secure as possible, e.g. there may be limited or no MAC (integrity/anti-tampering), and the encryption mode will localise and limit the required on-disk sectors to be updated (see this Wikipedia page on XTS as used by TrueCrypt for possible problems). These can be leveraged in an active method of attack, e.g. if you can convince someone to store a crafted file (see Water-marking attacks). I'm not aware of any methods which can use these limitations to attack or identify disk encryption (cold-boot attacks seem to be the preferred method, or at least get more attention).
Update: (Oct. 2013) while reading about the upcoming TrueCrypt open audit project (and here) I found this document:
Security Analysis of TrueCrypt 7.0a (PDF) from August 2011.