Note that not every C++ compiler neccesarily uses a vtable pointer at all. For example, the Watcom C++ compiler, 20 years ago, implemented method calls by reserving a function pointer for each method within the object itself; the
new operator initialized each of these function pointers separately, every time it generated a new object.
The very idea of the vtable is to optimize this. At the time an object is generated, its exact class is known. The vtable allows the compiler to assign all those "function pointers" at once (by putting the address of the vtable in the object), at the cost of one more indirection every time a method is called. But anyway, the vtable for any class that may be instantiated is known at compile time*. Which means the vtable can be pre-initialized at compile time, which means it's bound to be put into some initialized data segment.
So for code that was generated by a current C++ compiler, you should be able to assume that all vtables reside in an initialized segment, not the heap or the stack.
However, if you're trying to write a decompiler, or a tool that automates dynamic analysis in some way, you should at least check for this condition. If i wanted to obfuscate my code, i could easily implement a function in assembly, that takes an input pointer to an object, generates a copy of that object's vtable, possibly modifies a vtable entry or two, and adjusts the vtable pointer to reference the copy. If you write an analysis tool that becomes well-known, this might even be a technique an obfuscator uses to specifically defeat your tool.
So while there shouldn't be a reason why vtables might be put anywhere but in initialized segments now, i wouldn't want to rely on this in a general case.
(*) I haven't used C++ for a long time, which means i haven't followed the newer specifications closely. I can't guarantee that C++11, or C++14, haven't introduced some weird construct that would need to construct vtables on the fly. But i'd be quite astonished if that was the case.