The Primary Key
The OpenPGP primary key holds your trust. If your key gets certified, those certifications will be issued on tuples of primary key and user ID. Outgoing certifications (on other keys) are also exclusively issued by your primary key. User IDs and subkeys are all coupled to a primary key. All in all, your primary key is the entity the glues everything together.
What capabilities your primary key has depends on the algorithm chosen and what capabilities are actually enabled (you can change this when running GnuPG in the --expert mode). All primary keys must have the certification capability C, but can have signature capability S (which must always be supported, as certifications are also signatures) and finally encryption capability E (which is not supported by all algorithms that fit a primary key, for example DSA can only be used for certifications/signatures, not for encryption).
Subkeys
What I don't understand at this point is what happens in case my sub-key expired, but the public key is still present and valid. Will gpg fall back to use the public key to encrypt and validate data?
Which subkey is chosen is implementation dependent, usually they will choose the newest non-revoked key capable of what you want to perform. If you add another subkey, this will be chosen. If you remove all subkeys, the primary key will be used -- given it has the necessary capability bits set. If the primary key does not support the required capability, the key cannot be used at all!
In GnuPG, you can enforce a specific subkey: by specifying the key ID followed by !. For example, if you want to enforce usage of subkey DEADBEEFDEADBEEF as a recipient, use the option --recipient DEADBEEFDEAEDBEEF!.
Subkeys can be arbitrarily revoked and regenerated without losing reputation in the web of trust.
I'm also not really sure about the exact role of the public key in case of the existence of sub-keys. My guess is that it's only used to validate the sub-keys before they are used to actually encrypt/validate, is that correct?
This is not necessary, but considered best practice. Lots of people even keep the primary (secret) key offline.
Expiration Dates
Does it still make sense to use an expiration date for the public key in case all sub-keys have an expiration date set?
Expiration dates are a reasonable thing to use on subkeys, as they require the sending party to update your key after a given time. They can be changed arbitrarily, though. This is also the reason why expiration dates on primary keys are not a reasonable thing to use; if the attacker gets hold of your primary key, he can simply change or even completely remove it, even if your key already expired! See "Does OpenPGP key expiration add to security?" for a more in-depth discussion.
Instead, have a pre-generated revocation certificate at hand (and in your backup).
However, what I want to do is to set an expiration date on the public key as well, while keeping the secret key non-expiring. How can I do this?
I think you're confusing public and primary here. The expiration date is always set on a public, special "configuration" signature on your primary public key, but issued by your primary secret key (so it can be verified through the public primary key). If you really want to specify an expiration date on your primary key, you can still change it at any time anyway, the old expiration date is simply overwritten.
But as discussed above, an expiration date on primary keys is providing false security, anyway.
