It's probably just me, but i don't fully understand what your problem is. I think I might be able to help though. First of all, you should try not to update your buffers whenever possible. If you have an object that never changes its form, other than the transformations like rotating, scaling and translating, then you should never have to update the buffer. If your doing animation, you will have to update the buffer though, and in that case, you should use dynamic buffers.

Also, I don't know about other people, but i usually have one buffer per mesh (but i use one buffer per subset of that mesh if i'm doing animation). Of course you could just through everything into one buffer, but you don't really need to do that.

With classes and instancing, this is just a suggestion, but instead of creating a buffer for every initialized object, you should have a parent class that holds the buffer, and children classes that use that buffer (for example if you have npc's running around, you could use the same buffers for them, just changing their colors or whatever else needs to be changed)

If you want to put all the stuff into one buffer, you'll need to get all the vertex and index information ready before you create the buffer. If you want to update the buffer dynamically though (can only be done with a dynamic usage and not a default usage buffer), then you can lock the buffer, overwrite the information in the buffer, then unlock the buffer. If you want to add more stuff into the buffers though, you will have to know when you create the buffer how big the final buffer will be, since you can have empty space at the end of a buffer.

I reread your post again, and I think i understand a little better. do you mean you want two of the same meshes rendered? or two entirely different meshes?

If you want two of the same meshes, all you have to do is render them twice (or however many of them you want), changing their world space matrix before you render them.

If you want two different meshes, all you have to do is create two different sets of buffers, and bind them to the IA before you render them.

After initializing a vertex buffer (lets say one of the 16 available)....

Danger! It appears you have not understood what a vertex buffer is.
You can create and fill a very big amount of vertex buffers.
You can bind/use only 16 of them. Notice there's a big difference conceptually, regarding what you're trying to say. Or perhaps I'm just worrying too much.

1. how would you give the next mesh the ability to use that same buffer?
2. Would it be just a case of changing the vertices you would have attached (I was thinking this would be it)?
3. its the scenario were a class had been made with the vertex buffer initialization function, would I been in trouble when I load multiple instances?
4. would that likely mean that the same initialization would be overloaded and could possibly cause issues with rendering?
5. Is it safe to embed a vertex buffer initialization in a class for meshes whose instances may be created and needed multiple times?

1. Short answer: you don't, because the buffer size cannot be changed. Ok, we are taking to invest some effort into making this possible. I suggest to take a look at this thread. I will write it again: most apps can take it easy and use a buffer for each unique mesh. You can indeed get a lot of mileage.
   But... if you're really sure you want to invest effort in this, you'll need to somehow pool mesh load requests and sum their contributions to figure a buffer size, then fill it, then adjust the batches accordingly. I strongly suggest against modifying already used buffers... it's totally not worth it.
2. No, the vertices themselves would stay the same (they would get dumped to a different VB offset), you need to change the batch and the indices instead. Or use index adders, or VB offsets...
3. Multiple instances of the same (static) mesh are totally irrelevant to buffer creation and initialization. They are the same mesh. Animated meshes are a different story. As long as they are kept synchronized, they will behave like static meshes... somehow. But you probably don't want to do that... and I'd rather not elaborate on this very much. Sometimes, the meshes are independently modified on the CPU and then sent to GPU, sometimes they are deformed using shaders... who knows what will fit best for you.
4. I fear I don't understand this.
5. Yes (if you do it correctly), but you'll end up wasting N times more memory!