In message signing, there is no encryption. Otherwise we would call it encryption.
A signature algorithm is, nominally, the combination of three sub-algorithms:
Key pair generation: that algorithm produces a brand new public/private key pair, using some strong random source, and using as parameter a "security level" to achieve (i.e. the size of the key that is to be generated).
Signature generation: inputs are the message to be signed m and the private key. The output is the signature value s.
Signature verification: inputs are the message m, the signature s, and the public key. Output is a boolean value: "true" if the signature matches the message and the public key, "false" otherwise.
The signature generation and verification algorithms are supposed to be able to process messages of arbitrary length, possibly gigabytes. And they do. Existing signature algorithms are already very efficient at handling huge inputs. So there is no problem which would require some additional construction, contrary to asymmetric encryption where something else is needed to cope with the severe limitations of these algorithms.
Most texts that talk about hybrid encryption say that we need to do that because asymmetric encryption is slow, but that's wrong. The real reason why hybrid encryption is used is because known asymmetric encryption algorithms cannot simply process messages of arbitrary length, and we have no real idea about how we could alter them in order to do so securely. Basically, the "chaining modes" for block ciphers do not have equivalents for asymmetric encryption that would be obviously safe. However, signature algorithms never had a limitation on input length to begin with, so that is a non-issue.
It so happens, internally, that most signature algorithms are efficient at handling large inputs because their first step is to process the complete message through a cryptographic hash function, and then work only over the hash value. This is a design element of most signature algorithms and should be of no concern to outsiders who just use the algorithm. It does explain, though, why some people discussing about "RSA signatures" suddenly begin to talk about hash functions such as SHA-1: this is because the signature algorithm includes, as one of its building elements, a hash function. Note that some algorithms do not work exactly that way; it would be wrong to claim that all signature algorithms begin by simple hashing.
Ultimately this is a matter of terminology. In the case of asymmetric encryption, e.g. RSA, it is traditional to talk about "the encryption algorithm" as using only a short input; and any extra symmetric encryption layer is considered to be, indeed, some extra, outside layer. However, in the case of digital signatures, the same tradition holds that the initial hashing step is part of what we call the "signature algorithm".
There are some good reasons for this terminology choice; in particular, we want the hash function to be part of what we call the "signature algorithm" because using a signature algorithm like RSA or ECDSA without a hashing step (using a "short input" directly with no hashing) may induce severe weaknesses. However, at its core, it still is a terminology issue.