Usual software handling certificates (e.g. Web browsers) don't validate in the past; when they consider a certificate (e.g. for a SSL server), they want to know if the certificate contents are trustworthy now. The "certificate stores" as managed by operating systems relate to this model. A "trust anchor" (aka "root CA") is either trusted, or not trusted. There is no notion of "it was trusted".
Validation in the past makes sense only in the presence of time stamps: a document is signed, and a time stamp is applied on the signature (or on the encoding of the document and its signature). The time stamp is to be verified at the current date (so the TSA certificate must be valid now), but then the signature itself, and the signer's certificate, can be validated at the time stamp date. This allows for verifying signatures even long after the relevant certificates have expired, although it requires that additional objects like CRL or OCSP responses are timestamped as well; additional time stamps may have to be applied at regular intervals. There are some emerging standards for such a process, e.g. PAdES (with the "long term" format) or ERS (which deals only with the time stamps part, but does it well).
In any case, such usages need a notion of time ranges attached to trust anchors. There are ongoing efforts (especially in the EU) for defining a standard format for that (called TSL) (the EU tries real hard not to say that this is a list of "good root CA", but everybody understands it that way). Validity dates are attached to each root CA in this list.
Some software which does validation in the past may use the OS "trusted root CA" certificate store directly. Indeed, a "trust anchor" is, nominally, the combination of a name (an X.500 Distinguished Name) and a public key (see RFC 5280, section 6.1.1, item (d)). However, it is widespread practice to use certificates as an encoding format for root CA. Such a certificate will include the name and public key, but also other fields, in particular two dates for a validity range. Therefore, some applications will use the root CA dates as indicative of the time range during which the root CA was indeed to be trusted.
In that context, what you are looking after is doable. Indeed, it suffices to modify the dates in the root CA "certificate". First export it as "raw DER" (not PEM / Base64). Then open some binary editor and change the dates in it; they use either
GeneralizedTime, so their internal representation is based on ASCII.
UTCTime uses the
YYMMDDhhmmss format (two digits for the year, two for the month, and so on); with
GeneralizedTime, things are similar except that there are four digits for the year (and there can be milliseconds). Just change the year, month and day fields to fit your needs. Once the certificate has been modified, import it back into your trust store and remove the original one. And voilà! you have your root CA with modified dates.
Of course, modifying the certificate contents that way breaks the signature which has been applied on the certificate. But this is a root CA: it uses the encoding format of a certificate as a convenience, but this is not a "real" certificate. The signature is there because the certificate format has a non-optional slot for a signature, but nothing actually verifies that signature. Indeed, the certificate is often self-signed. Therefore, breaking the signature should have no importance.
I repeat, though, that these dates matter only in the context of some software which does "validation in the past", so all of this depends on what such software actually does: root CA certificates in the OS trust store embed validity dates (and you can modify them "manually", as described above), but software which does past validation does not necessarily use these dates to manage the root CA certificates. It may well use another source, e.g. a TSL.