The only "verify" operation in gnupg is signature verification, which basically encrypts the hash of the encrypted file with a public key (=sign).
In my opinion this means that if the output bits are corrupted while the file is being encrypted, the hash will be calculated against the corrupted file. You will never discover this by verifying the signature of that file since you signed an already corrupted file.
It appears the only way to positively verify an encrypted file against corruption is to go through the lengthy process of decrypting the generated file and compare its hash with the original.
And this is what Sepero offered above, but instead of "You could verify..." it should be "The only way to verify..."
Update - to drive the point home:
A few minutes ago I did just that: Splitting a 9.8GB back-up file into 5 rar pieces, and each piece symmetrically encrypted by gnupg. Before deleting the rar pieces, I verified the integrity of the encrypted pieces as I discussed above: 1 out of the 5 did not pass the hash test. I decrypted again that piece, and now the decrypted piece's hash did match the original rar piece.
I binary compared the bad decrypted rar part with the good decrypted one, and the only difference in those 2GB files was one byte: C8 vs. 48 - which is caused by a 1 bit flip (i.e. 11001000 vs 01001000).
The moral of the story is that if, on a good WIN7 system and a good HDD, gnupg can flip a bit on decryption, it could do that on encryption too. I will never skip again this integrity verification step.