Your analysis is pretty much spot on, except a few bits of info missing here or there.
The main module file is a .rim (or a .mod) containing the .are, .git and .ifo files. These are the three main files which drive everything else; as you noticed, for example, you can find a list of rooms for the module in the .are, and so on. We can currently build these with KotorTool and Kgff; the latter is the current best shot at working with gff files (of which .are, .git and .ifo are variants), while KotorTool will easily let you assemble the separate files into a .mod.
Along with these, you'll usually find another .rim used by the module, containing a variable amount of other game resources, like placeables, sounds, dialogs etc; all sourced from the main three files. In a custom-made module these will be included into the one .mod file. We're currently able to modify most, if not all, of these.
The .wok files are used for area walkmeshes, and determine where you can walk and where you can't. I recently almost completed cracking the wok format (I still have to figure out one field in the file, but it doesn't seem to affect the walkmesh functionality so I zero it at the moment); the current (0.1) version of KAuroraEditor is able to import/export them, but it has a couple of bugs and a couple of spots where it could be more precise; I corrected those and the next version will be able to produce binary woks which are nearly identical to the ones produced by whatever tool Bioware originally used. So I think we can assume walkmeshes are now done.
The one missing format was the lightmap, but while working on improving the current .mdl functionalities (the current state of the art is mdlops) I realized that those are essentially just another texture added to the model. So, if you give me a lightmap file (i.e. a .tga) produced by some 3d rendering program, and a set of UV coordinates in a format which I know and can read, I can include the lightmap in the binary .mdl (and mdx) file. The .mdx stores a variety of additional data related to the nodes (i.e. the objects) you find into his .mdl; most notably, it stores a duplicate of the vertices, the vertex normals, and zero to two set of UV coordinates for the textures you might have in the node.
Up until now, it was believed lightmaps were needed for the engine to render the room models; but I noticed several models in the game which do not have any lightmap and I now believe they're not necessary for scratch-built areas; they just make the room look better, if done properly.
I'm currently working on the 0.2 version of KAuroraEditor which will have the capabilities to import/export .mdl, .mdx and .wok files; I can even make all three in one go, provided you give me a valid ascii .mdl file containing both the area model and its walkmesh. The .mdl binary importer will feature some improvements over the current mdlops state of the art, and I believe it will be the best shot at an actual module editor. Because right now, when I try to create a scratch-built module, I can have a properly working walkmesh but not a properly working .mdl. Something is missing and I'm trying to fill in the gaps. Note also that mdlops does not have the ability to properly import every type of node into a binary .mdl; the bones used in animations and some info on the saber nodes are still unknown. I've decoded a few additional bits, but not yet enough to write a complete binary importer, unfortunately.
Further improvements would then be mainly in adding gff-format file editing capabilities, as these would mean automatic generation of several fields in the three main files. The KAurora version I'm working on also has area-rendering capabilities [the work in progress I'm using on my PC can render the area models correctly applying textures and lightmaps; it automatically goes looking for them into the treenode resource structure and convert tpcs to tgas on the fly before passing them to the Direct3D engine], so it wouldn't be too difficult to add moving capabilities to the camera (right now I only put in a step movement in 25m increments in the six directions, with no rotation possible); this would allow the creator to walk within its model and look at a pretty close approximation of the in-game rendition. From there, with gff editing in, it's trivial to add capabilities like e.g. double clicking to add a placeable in the spot you just clicked.
Further formats you forgot to mention:
.txi (extra texture info) --> a plain text file containing opengl instructions on what to do with textures; only used for lightmaps in Kotor, and most of them are pretty standard
.vis --> plain text file containing a list of which rooms can be seen from which other rooms. Presumably used to help the rendering engine during the culling process - no sense in working on rooms you can't see. Editing them manually is pretty trivial, as it can be done with notepad. I have no clue how you can automatically compute them, though; it is probably some pretty advanced capability of 3d modeling programs.
pwk = placeable walkmeshes, dwk = door walkmeshes; I didn't work on them as KotorTool was already able to produce those. They are essentially little walkmeshes which get superimposed on the area one to avoid the PC walking over objects or doors. IIRC they are a subset of area walkmeshes, so I'll add them in KAurora sooner or later.
.pth are path files used with waypoints. Text files, IIRC; not much is known on them. They will have to be further analyzed, but they are hardly essential to the area itself; they're mainly useful for advanced NPC functions.