Erm, why wouldn't it be a good idea?
Because one would normally just return a function-local vector by value which is much cheaper (with move semantics) then heap allocation of a container + 2 x shared_ptr construction.
Moreover, as vector is returned wrapped inside a shared_container_iterator (well, a pair of those) one may pass it directly to Boost.Range or Boost.Foreach (yep, std::pair supported) without spending too much time thinking when and how to allocate and release memory as shared_ptr does that for you.
All well supported also with just returning a container by value.
I don't really know why you should feel bad about allocating a vector from heap as std::allocator will use heap anyway.
This way you get 2 heap allocations + shared_ptr<> construction as opposed to just internal allocation of vector (using allocator). This is especially bad if returned vector turns out to be empty. In that case vector might not do allocation at all so vector creation and return are practically free.
If I'd had to optimize (as in Optimize, not some needless micro optimizations) some vector / array related operation, I think I'd forget any std container, let alone shared_ptr, in the first place...
Interesting. What would you use instead of a vector + specfic allocator when "Optimizing"? Continuous block of memory is rather hard to beat in terms of data processing speed. Anyway, still not convinced of good use case ;) Is there any? Cheers