The cipher suites in SSL/TLS do not specify minimum or maximum sizes for the asymmetric keys involved in the key exchange or the certificates (the old "export" cipher suites specified maximum sizes, but these have been deprecated). Annex F.1.1.3 contains this text:
Because TLS allows the server to provide arbitrary DH groups, the
client should verify that the DH group is of suitable size as defined
by local policy.
which means that it is up to the implementations to enforce the size constraints that they wish to see enforced.
In practice, RSA and DH keys which are way too small (smaller than 512 bits) will be rejected by many implementations (and when using RSA key exchange without DHE, there is an absolute minimum of 465 bits for the RSA modulus, otherwise the key exchange cannot take place at all). Many implementations will also reject keys beyond a rather large size (e.g. more than 4096 bits), because of internal constraints in the implementation.
If you want to make sure that short keys will make the handshake fail, then you have to configure or implement it yourself on the system you control (client or server).
Microsoft has pushed an update which deactivates support for RSA and DSA keys shorter than 1024 bits -- which implies that prior to this update, they were supported. However, the Diffie-Hellman group used with DHE is not from the certificates layer, but chosen by the SSL server code itself.