STL containers require the stored values to be copy constructible and assignable. const T is obviously not an assignable type for any T, but I tried to use it (just being cu
This simply shouldn't work. At §23.1 ¶ 3 it's specified, as you said, that objects stored in a container must be CopyConstructible (as specified at §20.1.3) and Assignable.
The Assignable requirements for a type T are that, being t and u of type T, you can do:
t = u
having a T& as return value and t equivalent to u as postcondition. (§23.1 ¶4)
Thus, const types are clearly not Assignable, since doing t = u would raise a compilation error (§7.1.5.1 ¶5).
I suppose that this is a bug in Microsoft implementation. g++ on Linux emits the typical 25 kajillion-lines template error if you even try to instantiate a vector (tested both with and without the -std=c++0x flag, just in case).
By the way, this is also explained in detail in this IBM FAQ.
In theory, as @James McNellis said, the compiler is not required to blow up on the vector instantiation (if it's undefined behavior anything can happen - including everything working fine); however, on the assignation statement there's a violation of the standard that should produce a compilation error.
In facts, the operator[] member returns a vector; that one is required to be an lvalue of T (§23.1 ¶5 table 66); since T is of a const type, it will be a const lvalue. So we fall down to (§7.1.5.1 ¶5), which defines code that tries to perform an assignment to a const element as "ill-formed", and this demands a compilation error or at least a warning, because assignment-to-const is a diagnosable rule (§1.4 ¶1-2) (no "no diagnostic is required" statement is specified).
Final edit
Actually, @James McNellis is right; once you've invoked undefined behavior by instantiating vector, the usual rules stop having value, so the implementation is still standard-conforming whatever it does - including removing the const from the element type or generating the usual nasal demons.