The "export ciphers" were defined in SSL 3.0 and TLS 1.0, but they implied that symmetric encryption relied on a 40-bit key only; this is highly breakable in practice. Notably, the reduction was direct (the key has length 40 bits exactly), instead of a reduction trick with a 40-bit key space (as can be done in RC2), so precomputed tables can be used to break this encryption instantly. Using an "export cipher suite" is not much better than not using SSL at all, at least against passive eavesdropping (for active attacks, we could argue).
This is reason enough not to use these cipher suites at all. Indeed TLS 1.1 and TLS 1.2 declare them as unsupported. Indeed, in annex A.5 of TLS 1.1, we find this text:
When SSLv3 and TLS 1.0 were designed, the United States restricted
the export of cryptographic software containing certain strong
encryption algorithms. A series of cipher suites were designed to
operate at reduced key lengths in order to comply with those
regulations. Due to advances in computer performance, these
algorithms are now unacceptably weak, and export restrictions have
since been loosened. TLS 1.1 implementations MUST NOT negotiate
these cipher suites in TLS 1.1 mode. However, for backward
compatibility they may be offered in the ClientHello for use with TLS
1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the
server did not choose one of these cipher suites during the
handshake. These ciphersuites are listed below for informational
purposes and to reserve the numbers.
Note also that the US export regulations have been lightened circa 2000, so these cipher suites don't make much sense nowadays.
If there is no cipher suite which both client and server support, then they won't be able to "do SSL".
I quite doubt, though, that there are people on the Internet with browsers who can only use "export" cipher suites, and these people are still able to connect to the Internet and try to use it. Even Netscape Navigator supported non-export cipher suites, and it was legally exportable (version 4.8 was from 2002; and versions prior to 4.8 crash on UTF-8 text, so they cannot be considered as "usable" at all...).
Also, note that export regulations are just that: export regulations. These means that it might be unlawful for a US-based company to send a product with strong encryption across the border, into, say, North Korea. This does not mean that it never happened. Only that if there is a browser with strong SSL encryption right now in North Korea, then, at some point, chances are that one export regulation of one country was transgressed. Or even maybe not: a given software may hop from country to country, in each case with full conformance with local export and import rules, and then reach North Korea, even if a direct USA-to-North Korea export would have been frowned upon by US authorities. There is no guarantee that export regulations are transitive (in the mathematical sense).
In fact, it can be surmised that if someone from North Korea can access ebay.com at all (meaning in practice that this guy is Kim Jong-Un himself), then he most probably uses a browser which can do strong SSL encryption.
Summary: consequences of not supporting "export" cipher suites are, in practice, nil.