What Microsoft calls "issuance policies" or "assurance" are known as Certificate Policies in X.509 (see section 4.2.1.4). A certificate policy is defined as such:
In an end entity certificate, these policy information terms indicate
the policy under which the certificate has been issued and the
purposes for which the certificate may be used. In a CA certificate,
these policy information terms limit the set of policies for
certification paths that include this certificate.
The whole idea of an OID is to uniquely and unambiguously identify an "object" (which can really be anything, including abstract concepts) in a worldwide naming hierarchy. As such, randomly generated OID totally defeat the purpose and cannot be condoned. In the case of certificate policies, the OID should "point" at a specific policy, i.e. a document which defines the conditions under which the certificate was issued and for what it may be used. You should obtain an OID subtree: any organization can obtain its own subtree from the IANA (it's free and permanent). Then you allocate the OID in that subtree in any way that you sees fit.
That being said, certificate policies make sense as part of the certificate validation process described in section 6 of RFC 5280 (see in particular step (a) of 6.1.2, (d), (e) and (f) of 6.1.3, and step (g) of 6.1.5). The validation process computes the set of certificate policies which are valid for the whole path, i.e. which appear in every certificate in the path. There are various subtleties, notably with regards to the special wildcard anyPolicy (that's 2.5.29.32.0, which Microsoft calls "All Issuance") and the policy mappings. However, if one of the CA certificates in the path does not have any Certificate Policies extension at all, then the vallid_policy_tree will be NULL, i.e. it all comes to naught. The certificate path will be validated "generically" but no specifically identified policy will come out of it.
The sad truth is that many CA use certificates in the way Microsoft promotes it, i.e. completely wrong with regards to what they were supposed to do; instead, they use certificate policies as a kind of fancy comment which software will consistently ignore (policies can be adjoined qualifiers, which can be plain text or a URL pointing to something which may or may not be a readable document).
Since certificate policies are so thoroughly misused, it is not useful to make the extension critical. In practice, you add the extension with a URL pointing to a 200+ page Certification Practice Statement as a PDF file, which at least demonstrates that you are serious about your CA business, to the point that you are willing to indulge in some heavy legalese. See RFC 3647 for guidance on writing a CPS.
