I'm not entirely sure on your exact situation, but here goes nuffin...
'the' viewmodel isn't normally known to the csqc except via stats. you normally have to just assume that its at pmove_org, if that is also actually known to your client... otherwise you'll have to check what you set VF_ORIGIN to, and just use that. Of course, this isn't entirely accurate if the user has tweaked some cvars and changed cl_gunangle etc cvars, but hey.
alternatively you're using .viewmodelforclient on your ssqc entities. those should end up with RF_VIEWMODEL|RF_DEPTHHACK set.
DP doesn't support RF_VIEWMODEL properly in that it behaves differently from 'the' viewmodel, and requires that the entity is moved along with the player (yeah, pmove_org or VF_ORIGIN is needed for that), whereas FTE just directly displays the entity relative to the view (which yes, means that you need pmove_org or VF_ORIGIN again for any effects spawned from it but at least you don't need it EVERY frame). For this reason you may wish to use just RF_DEPTHHACK and not RF_VIEWMODEL, and just manually position it, then you know exactly where it is. This is especially true if you want to kill that really annoying weapon bob (or if you want to make your own cooler version or whatever).
if its an entity that you spawned in csqc yourself, then how do you not know its origin?
if you're trying to use FTE's 'viewspace' particle property, then those particles should still be spawned in the normal place; they're not viewspace per-se, but rather they just move with the view. On the plus side, this means that the viewspace field is actually a scaler, and you can use smaller values to have them move slower than the view such that they don't go offscreen instantly but also do still lag behind dragged away by the wind, but yes they still need to be spawned at worldspace positions. Imho this looks better than them inheriting some proportion of the player's velocity, even if its not correct (be sure to spawn them in the position from the previously rendered frame, so that they can follow the camera change, and yes they won't work too well with splitscreen).
but yes, if all else fails, you might have some luck with the following:
bonepos = gettaginfo(theentitywithRF_VIEWMODEL, thetagindex);
vector viewspacepos = (vector)getviewprop(VF_ORIGIN) + v_forward * bonepos_x - v_right * bonepos_y + v_up * bonepos_z;
pointparticles(particleeffectnum("te_explosion"), viewspacepos, v_forward, 1);
or some such. I don't remember which way around those vectors are.
(you can transform the tag's orientation too if you need that, same way just ignore the vf_origin part)
but yes, VF_VIEWORIGIN means that the entity is meant to follow the camera. the issue is that the camera is not actually defined by anything other than the short sequence between clearscene/setviewprop(VF_ORIGIN) and renderscene. This means that gettaginfo etc will ignore it.