There is in fact no difference in security between a 128-bit symmetric key and a 256-bit symmetric key. The reason is that security against brute force is relative to the technological means available to the attacker, and there is no way that the technology in the foreseeable future will allow a 128-bit exhaustive search to be performed with non-negligible chances of success.
By "foreseeable" here, I mean "within the next 30 years". Anybody who claims to be able to predict technological advances for longer times is either a time traveller or a filthy liar. Note in particular that it I claim that there will not be, in the next 30 years, a quantum computer that is large enough to run key tests on 128-bit AES and can do so for 264 steps -- the latter condition being very non-trivial. It is of course conceptually possible that mathematical advances will be found, that would simplify exhaustive search, but this is highly speculative and there is no real indication that a 256-bit AES key would resist such things better than a 128-bit AES key (in fact there are some esoteric attacks, called "related-key attacks", which fortunately do not apply to practical cases, and for which AES-256 is weaker than AES-128).
Since there is nothing stronger than non-breakable, one can say that AES-128 and AES-256 are equally good for security. We may even say that AES-128 is slightly preferable, since it is slightly faster (but it won't matter much).
That being said, in OpenPGP format, passphrases are turned into keys through a string-to-key transform. The recommended one (the "iterated and salted" transform) hashes a long concatenation of multiple repetitions of the passphrase and the salt. The total size of that which is hashed is configurable, but the point is that each passphrase try should cost a lot. This mechanically increases resistance to exhaustive search. For instance, if the iteration count is such that a passphrase-to-key transform costs as much as about one million AES invocations, then you only need 108 bits of entropy in the passphrase to reach 128-bit equivalent security. Of course, increased cost is increased cost: you do not get extra security for free.
The iterated-and-salted S2K uses an inner hash function which could be SHA-1 or even MD5, but it is not needy with regards to the cryptographic robustness of that underlying hash function. Even if it is the very broken MD5, and even so MD5 output is only 128 bits, the iterated-and-salted S2K is defined in such a way that it can still keep about all your passphrase entropy in the resulting key. Thus, if you have 256 bits or more of entropy in the S2K input (the passphrase), and you want a 256-bit output key, then that output key will have at least 255 bits of entropy.
(If you have exactly 256 bits of entropy in the input, you expect a theoretical 255.34 bits of entropy in the output.)
To sum up: there is no "gotcha" in the way the passphrase is turned into an encryption key, but even if there was, you would still get a security level that is not different, in any practical meaning of the term, to the theoretical "256-bit" level.