In X.509, a certificate can be validated if it can be put at the end of a valid chain, where each certificate in the chain has issued the next one, and the chain starts with a trust anchor. The trust anchor is the certificate that you trust "ex nihilo", i.e. not by virtue of the certificate being signed by another, trusted certificate; the trust anchor is trusted by configuration. This configuration is, indeed, putting the certificate in the "root CA" certificate store.
When you put a certificate in the "root CA" store, this does not automatically means that your machine will begin to use this certificate as a CA, i.e. to validate other certificates. This merely means that the certificate is "trusted". Whether this certificate will also be accepted in the role of a CA depends on what is written in it (the Basic Constraints extension).(*)
To initiate trust, you must do "something". A Web browser must not trust transparently any self-signed certificate that it encounters; it would be a gross vulnerability. The user must make an explicit action to allow the self-signed certificate to be trusted for SSL; and, preferably, this action must not be a too easy one-click thing, because otherwise users will do it without even noticing it. Clicking through warning popups, however scary they can be, is a well-entrenched behaviour in human users; and, unfortunately, accepting a self-signed certificate without due manual verification leads to Man-in-the-Middle attacks.
In Windows/IE, the "something" needed to prime the trust system is installation of the self-signed server certificate in the "root CA" store. This requires some not-easy GUI invocations, and that's by design. It MUST NOT be easy.
For other browsers, things may vary, though the core concept is the same. For Firefox, installation of a self-signed SSL certificate is described as a "security exception"; Firefox has its own X.509 subsystem, completely disjoint from the one of the underlying OS. For Chrome, this depends a lot on the OS, the OS version and the browser version.
(*) There are subtleties. Old X.509 certificates, aka "v1", more than 15 years ago, did not support extensions at all, so there was no way to mark a certificate as "good for CA" or "not good for CA". This means that a v1 self-signed certificate, installed in the "root CA" store, will act as a CA, thus be accepted in the role of a CA, for validating other certificates. You should take care, when installing a self-signed certificate, that you do not open that door. Unfortunately, this depends on rather technical details of the certificate, so it is not easy to test for end-users.
