None of that is true. Aside from the very first line, none of that code compiles.
First of all, [T] isn't a Vec, it's a [T]. The type of vec!(1,2,3,4,5) is Vec<i32>. You can't have a value of type [T]; it always has to be behind an indirection of some kind.
Let's step back.
Rust wants to be able to efficiently take and pass around slices of arrays. A good way of doing this is to pass around bundles of (&T, usize): a pointer to the first element, and the number of elements. You can trivially create one of these from any contiguous storage, no matter where it comes from. For example, &[T] is a borrowed slice of some other storage. This raised the question of "if &X is a pointer to X, then what does [T] by itself mean?"
[T] then is the type of "some number of Ts stored contiguously". It says nothing about where they're stored, who owns them, how they're managed, etc. Just that some number (including zero) of T exists somewhere. You want [T] because you can build on it to create other, more useful types that do have something to say about where/how those Ts are stored. &[T] says they're borrowed and owned by someone else (possibly in the static data segment as a literal). Box<[T]> says you own them and have exclusive access to them. Rc<[T]> says ownership is shared. [T; 5] is exactly five owned Ts.
The reason Vec<T> exists is because a really common thing is to build up arrays element-by-element. It's basically Box<[T]>, but it keeps some extra space around to make appending to it more efficient. You can slice it to get &[T] because you can slice everything that's just contiguous storage to get &[T].
String and str is exactly the same thing except for the whole "must be valid UTF-8" thing.
So [T]/str are fundamental building blocks. Vec<T> and String are just things built on top of them, because [T] and str don't do much by themselves.