In a better world, TLS_FALLBACK_SCSV would not be necessary: SSL has been supporting downgrade-proof version negotiation since at least SSL 3.0, so a man in the middle should never be able to limit a connection to a version older than the mutually supported maximum.
However, out there are some broken servers that don't really support that kind of version negotiation; simply receiving an unknown, i.e. newer, version number, or unknown TLS extensions in a ClientHello causes them to crash. (Compliant servers would not crash, but simply tell the client that they want to use a lower version of the protocol; the connection would be established using the highest mutually supported version.)
Ideally, clients would simply refuse to connect to such broken servers; the problem would be swiftly fixed by the server vendor, and proper version negotiation would be restored.
As it turns out, quite a lot of server vendors or administrators couldn't be bothered to do that. Many browsers will now try to fix the problem on their end by connecting using a "legacy" ClientHello that doesn't trigger the buggy server behavior, which is essentially a second connection attempt using only SSL 3.0.
Unfortunately, this opens up an attack possibility for a man in the middle: By simply suppressing client connection attempts using new TLS versions to the server and simulating a buggy server response to the client, they force an SSL 3.0 connection attempt; the connection using SSL 3.0 will eventually be established, with the server thinking that the client uses a really old SSL library, and the client thinking that it is talking to a buggy SSL-3.0-only server.
Essentially, TLS_FALLBACK_SCSV allows clients to send a hidden version number in the downgraded connection attempt in a way that doesn't trigger the server bugs.
Informally, the conveyed message might be interpreted as follows:
Hey Server, even though I only claim to support TLS version $x$ in the version header, I actually support TLS versions up to $y$. If you support anything better than $x$, this means that there is something sinister going on here!
Practically, the backwards-compatible signal is a special "dummy" cipher suite that will be ignored by servers not supporting fallback prevention (whether they are broken SSL 3.0 or fairly recent TLS 1.2 servers).
Only servers supporting the draft specification will be able to interpret the signal and act accordingly; older servers will simply think that the client supports some additional cipher suites that they don't know about, and will continue the handshake as usual.