If you're choosing to use this particular abstraction (renders projected onto impostor geometry), you're probably going to be doing it for 2 main reasons: Z buffering and lighting. There are other benefits, to be sure, but these are the big ones. The Z buffering gets past some of the interesting sprite draw-order problems that have been highlighted over 30 years of isometric games, and the lighting just makes it look juicy.
But for both of these, you really want to have geometry that fits the rendered sprite that is projected on it. Cubes can work for many elements, as long as those elements are essentially cubic in nature. Since you are still going to try to avoid cases of intersection or clipping between objects, the occasional weird cube-like clipping artifact won't be too bad. But a mismatch between the rendered object and its impostor geometry is going to be very noticeable once you toss dynamic lighting into the mix.
So, no, there's really no one size fits all solution for impostor geometry. For this reason, I'd say that if you are looking for a paradigm to reduce your workload, this isn't it. Just go with a standard 2D sprite stacking approach instead, and deal with the edge cases as best you can. This technique ends up actually being more work, because after you have finished the intricate modeling of your rendered objects, you still have to perform modeling to obtain a good-fit impostor to stick in on. That second step can be skipped in a traditional 2D, at the cost of all the tradeoffs you have to make.
If you are willing to accept some lighting quirks, though, you can settle for cubes or portions of cubes for everything. It'll show up in lighting, but maybe you can finesse it so it's not that bad.
Alright. Thanks again for your help!