After a bunch of research on the problem, I concluded that the OS X GUI configuration package simply doesn't understand about any kind of routing except a single default route. The traditional BSD way to deal with this problem is to insert code into rc.local, but if I added a route command there, it had no effect or a bizarre effect. I experimented with LaunchDaemons and StartupItems, but they also had no effect or the wrong effect.
To make a long story (several days) short, the trick here is that you must use an ifconfig command in the rc.local script, even though at a later point in the process, the GUI-specified interface configuration will be done redundantly. If you do not do this, the route command will fail, because there will be no device configured for the bridging subnet.
Here is the critical portion of the rc.local script:
ifconfig en2 inet 11.22.33.5 netmask 255.255.255.252
route -n add 11.22.33.64/26 111.222.333.6
Note that 11.22.33 represents my Class C network; the "other" LAN subnet is .64/26 off of that, and the bridging subnet is 4/30 (a point-to-point subnet) of of the same Class C. On the other server, the script is:
ifconfig en2 inet 11.22.33.6 netmask 255.255.255.252
route -n add 11.22.33.32/27 111.222.333.5
Note that the LAN subnet is different, the bridging subnet is the same, but the two ports are swapped in terms of direction.
Once you understand that (1) rc.local is still the best place for this (not the GUI), and (2) you have to do an early ifconfig to help the route command do the right thing, adding static routes is really simple. Now, you could probably do it in LaunchDaemons or StartupItems, if you do ifconfig before route, but in truth, no daemon is launched here, and StartupItems is deprecated, so rc.local may be the best option.
It goes without saying that you have to make sure that the ifconfig in rc.local matches what the GUI assumes about the interfaces, otherwise you're in big trouble.
Incidently, I'm currently still testing the two servers in a "sandbox", using an Ethernet cable to connect them. I haven't tried out the EtherBridges yet (but assuming they work as advertised, there doesn't seem to be any reason they won't fly right out of the box).

