[Note: it's not clear from your question how deep an understanding you have of PKI. As it's worded, there are some pretty glaring conceptual problems, so bear with me. Maybe you already know all this, and just need to tighten up the wording of your question, in which case I will remove 90% of my answer.]

##PKI Fundamentals

I think we need to go back to basics on how Public Key Infrastructure and certificates work. I am going to shamelessly steal a photo of a certificate chain:

In this scenario, User1 would be your document signer, which sign documents using a certificate issued by some Certificate Authority (CA), which could be a self-signed root CA or could be an intermediate CA with a root above it.

###Validating a certificate chain

Let's say that I as the client want to validate the signature on a document that User1 signed. The procedure would be this:

1. Validate the signature on the document: hash the document yourself, and then use the public key in User1's cert to check that your hash matches the one in the signature field.
2. Validate User1's cert: Ok, I know that the document was signed by the key identified in User1's cert. How do I know that this key actually belongs to User1 and that this isn't a fake cert? Well, this cert is signed by an IssuingCA, so I will validate the signature on User1's cert against the key in the cert for the IssuingCA.
3. Validate the IssuingCA's cert: Ok, I know that User1's cert was signed by the key identified in the IssuingCA's cert. How do I know that this key actually belongs to the IssuingCA and that this isn't a fake cert? Well, this cert is signed by the RootCA, so I will validate the signature on the IssuingCA's cert against the key in the cert for the RootCA.
4. Validate the RootCA's cert: Well, since it's this cert is self-signed, there's no way to validate it, so I will check that it matches bit-for-bit (or that its hash matches) one of the certs that I've pinned (aka is in my trust store).

##Your Situation

You say:

Our team has looked into certificate pinning but decided against it for a couple reasons. ... We'd rather just validate against the system trust and let a public CAs CRL take care of revocation for us.

Then how, pray tell, are you doing that validation if you haven't pinned the root cert?? How are you validating the signature on the CRL to make sure that it hasn't been faked? What happens if I whip up my own OpenSSL CA on my linux box and issue myself a cert with the identical subject as your cert (ie is bit-for-bit identical to your signing cert except for the public key and signature)? Please tell me that your software would reject it.

##Answering your questions

In general, is it valid to trust the information that's provided in a certificate's subject?

Uhh, no. Not unless you've validated the signatures on the certificate all the way back to a root cert that you have pinned.

Is there a way for me to obtain an x509 certificate from a pre-trusted authority that contains information in the subject that has not been validated?

I'm not sure I understand the question. Validated by who? A public Certificate Authority (CA) should verify all information in the Subject and SubjectAltName fields before issuing the cert. If not, then that CA deserves to go out of business. Your client software should also validate the contents of a certificate every time it sees one by tracing the signatures back to a pinned root.

Do we have to verify that the certificate has the "Code Signing Certificate" extend key usage to get that guarantee?

Umm, that depends, is it signing code? ie are the "documents" in question executable software (.exe files, or installers)? If not then you should be checking for the "Digital Signature" extension. (The point of this extension is to make sure that a certificate / key gets used for one thing and one thing only. If a key gets "re-purposed" halfway through its life, this can lead to vulnerabilities).