The SocksPort aspect is easy. Just start multiple instances:
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9050
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9051
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9052
...
It's the DnsPort aspect that's hard. The default is port 53. You could bind each instance to a different DnsPort:
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9050 --DnsPort 9090
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9051 --DnsPort 9091
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9052 --DnsPort 9092
...
And then you could map port 53 for each application to the proper DnsPort.
The canonical answer about entry guards is that variety greatly increases vulnerability to relay adversaries. The idea of using just one entry guard, and keeping it longer that the current two-month default, is under discussion. You could add "NumEntryGuards 1" to "torrc-defaults", and just have one per instance. And you could use "EntryNodes node,node,…" to specify trusted entry guards with good bandwidth, either in "torrc-defaults" for all instances, or individually in each command line.
The strategy of fragmenting activity into unrelated components, and then isolating and disassociating the components, is useful in two ways. First, it protects anonymity. As long as the components are sufficiently unrelated and disassociated, adversaries can't build a coherent persona model, even if they can see each of the components, or at least their effects. And with no coherent persona model, matching to known persons is problematic. And second, it limits the impact if any component is compromised.
However, I don't think that isolating and disassociating by entry guard is all that useful by itself. Typical relay adversaries run lots of attractive entry guards. Over time, their entry guards scan virtually all clients using the default: three entry guards, rotated based on the GuardLifetime parameter from the consensus directory (currently two months).
Over time, they seek circuits that use both one of their entry guards, and one of their exit relays. Whenever they find one, they log whatever information is available about the circuit, and also about the destination. Even if there's end-to-end encryption, they get an IP address and some information about the protocol and whatever. And the logs obviously include client IP addresses.
Given such logs, it's trivial to select client IP addresses of interest, based on destinations of interest. As long as an adversary's entry guards can scan through most clients, even if it takes a year or more, they can eventually associate some set of the anonymous components with an IP address.
Therefore, isolating and disassociating by entry guard is an effective strategy only when your entry guards are highly trusted. If I were doing this, I would probably use my own entry guards.
Using maximal isolation via some concatenated mix of VPNs, JonDonym and Tor, I'd lease several small hosted servers (not VPS). I'd pay with insanely highly anonymized Bitcoins, and/or cash by mail. I'd use dm-crypt/LUKS FDE, with dropbear for remote decryption/mounting. Any server that spontaneously rebooted would be dropped as untrusted. And I'd use Tor-ramdisk.
Even so, some of those entry guards might be tapped by hosting providers, ISPs, etc. To distribute trust, I'd site them across as many different political/military power blocks as possible. I'd also specify entry guards (bridges, really) as domain names, and use DNS-based fast flux (Proximax) to rapidly cycle through my set of semi-trusted entry guards.
On top of that, it might be useful to route each Tor client through a different JonDonym mix, with a premium account funded by insanely highly anonymized Bitcoins. I would access JonDonym via multiple nested VPN chains, using a mix of trusted VPN services and private VPNs, set up as described above for the entry guards.
