Yes, it should be possible to decipher a chunk of a large RFC 4880 / OpenPGP file (without deciphering the bulk of what's before), assuming the (private) key necessary for sequential deciphering is available, and the entity that prepared the enciphered file did so without using the file format's compression feature (even though using it is the default and most common). There is an attribute in the public key format allowing the recipient to require that compression is not used (see RFC 4880 section 13.3.1), thus what's asked should be possible.
However
- The integrity of the separately deciphered chunk can not be ascertained; it seems that as a bare minimum, the file should be integrity-checked at least once before starting to decipher it as chunks.
- There is a risk that some untested implementation (or one predating the OpenPGP spec) does not honor the "don't compress" flag correctly (that is, compress even though one of the intended recipients forbids).
- Usual libraries implementing OpenPGP decryption are not designed with direct access in mind, and will need to be modified, as follows.
The general idea would be to process the beginning of the file up to the point where the symmetric key and algorithm used for encryption of the bulk of the data is known; then (when the chunk to decipher is not near the beginning of the file skip an integer multiple of the block size $b$ (8 octets for 3DES, 16 octets for AES), starting reading at the block preceding the block containing the fragment to decipher.