Depending on how you're getting traffic onto Tor (i.e. are you using the SOCKS proxy or silently redirecting traffic to the relevant port) you may be able to achieve something similar to what you're attempting using other tools first.
For example, I have a VM running an MUA, it should only ever connect to it's mailserver's over Tor. To enforce that, my router runs Tor and an iptables rule ensures that all traffic from that VM leaves my network over Tor (there are some other concerns with doing it this way, but they aren't relevant for what I'm trying to say).
There's no technical reason I (or, you) couldn't add a rule to first push that traffic through some sort of (semi)transparent proxy so that filtering can be performed at application level.
There are a number of reason's you might not want to do it though:
- It complicates troubleshooting connection issues
- You've just inserted an extra listening point for an adversary to use
- If you're using a transparent solution and it breaks, you may find yourself working without your extra level of 'protection'
- Depending on your solution, it may change your request signature (a lot of work has gone into TBB to make all look the same, you don't want your user-agent to suddenly becomes 'squid' for example)
In my setup, traffic transits my network in the clear (at least in a metadata sense) before reaching Tor, there's no reason you necessarily need to do that as you could set something similar up on a single box.
So whilst tor won't do application level filtering for you, you can insert some filtering into the chain, as long as you weigh the risks (and I've likely omitted some)