This rabbit hole can go pretty deep, so really it's up to you as to how far you want to go, and how fast.
There are many different ways of storing, manipulating, and ultimately drawing 3D assets, and the technical details vary widely between projects. Scenegraphs are one approach that is fairly common, but there are other methods as well, which may or may not be suitable depending on your needs. Animation systems are as diverse as snowflakes. You can easily specialize in nothing but animation programming and have a solid workload for the duration of a project.
It also depends a lot on what environment you expect to be working in. If you're talking about solo projects, or small team collaborations, you can pretty much expect to have to understand a lot of artist lingo to get things done. In larger teams, it's easier to hide and let other people deal with the tidbits you aren't interested in :-)
Ultimately, a lot of best practices vary by engine and team, and you will almost always be learning in some way or another.
With all that disclaimer boilerplate out of the way, I'll address some of your specific questions.
Models and animations can be stored separately. Generally a model is just a mesh, skin details, and texture/material details. You then combine this with an animation rig (totally separate beast) and dynamically re-skin the mesh as the animation changes the pose of the model. There's a lot of moving parts in these systems (no pun intended) and a lot to study up on.
Modelers and animators are often separate people, because they are very different skill sets. On large teams models are typically handed off to animators, or handed back and forth and refined over time until a final asset is ready. Smaller teams may see these roles taken on by a single individual, but it's rare to find someone who is really good at both.
Requesting assets is going to depend almost entirely on your tool pipeline and engine. At a minimum you should be able to provide an artist with an exporter or converter that can take data directly from a popular tool (or file format) and prepare it for use in your engine. Most engines come with this stuff, so until you're deep in roll-your-own territory, this isn't much of a big deal. The specifics of all this are going to change heavily based on how your engine of choice is designed, so be prepared to learn several approaches and hate most of them ;-)
As for the town scene: it is generally advisable to compose large things out of small things. If you have a building, store it as a building model. If you have chairs and tables, each should be a separate model. This is good for a number of reasons (reuse of assets, runtime resource instancing, and so on) that will become clearer with a little experience. Sticking everything into a giant monolithic model is often referred to as "baking" and is generally a bad idea, with some very specialized exceptions. (You'll know it when you run into one.)
If you're interested in the art/code interface, there are two things I'd suggest. First, lurk on forums dedicated to modeling or animation. You'll find lots of terms that you'll need to look up, and lots of general ideas for how things are done. Second, get ahold of an engine like Unity, Unreal, or even an older one like Source, and look at how their tools and asset pipelines work.
Most teams won't really talk much about their asset pipelines, but that's typically because pipelines are hard to do well and people routinely make bad ones. However, if you can, pick the brains of some tools developers from major studios. You'll learn a ton about how things work and what to do (and not to do).
