What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem.
The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the signature was correct, and act on that belief -- even if the signature is no longer verifiable at date T', e.g. because the signer's certificate was revoked in the mean time.
In the case of revocation, each revocation information (be it in a CRL or an OCSP response) comes with a revocation date. The field is called
revocationDate in a CRL and is defined in the following way:
The date on which the revocation occurred is specified.
So when a CRL says that a certificate was revoked on June 17th, at 14:10 +00:00, it also implicitly says that on June 15th, the certificate was not revoked. Therefore, if the recipient can somehow make sure that he received the email (and its signature) at a date prior to the revocation date, and that the stored email was not altered in any way, then the signature is still, conceptually, verifiable.
A serious hole in the theory above is that existing CA do not necessarily write revocation dates with all the needed accuracy. For instance, if you revoke twice the same certificate with Microsoft's PKI (Active Directory Certificate Services), then the revocation date will be the date of the second revocation, not the first. But if you manage certificates on smart cards with Microsoft's FIM CM product (Forefront Identity Management -- Certificate Management), then you will make such duplicate revocations.
In general, proofs of existence of some piece of data at a previous date rely on time stamps. For long-term archival of signed documents, still verifiable years after (not only after the signer's certificate has expired, but also after some of the intermediate CA certificate have also expired), you need to apply time stamps on a regular basis, like a layer of fresh paint. Some standards exist for that, but they are little more complex than simple CMS (CAdES builds on CMS, but with some rather hairy extra attributes). See this answer for some more discussion and pointers.