First, thanks for the quick reply.
I was able to set up a couple of test instances to try this config out, and as you predicted the results were not pretty -- although much further along than I'd been able to get on my own.
My assumption is that what we're facing here is a common problem -- when had to deal with integrating the various 3rd party apps that only support a flat DIT out-of-the-box (the strategy being to take a login ID and "construct" the rest of the dn around it, like "uid=[login id],ou=people,dc=example,dc=com"). The idea here was to try and create a flattened "view" of all our user entries so that we wouldn't have to constantly struggle with modifying some of these (poorly designed) packages.
I did do some variations on what you provided, without further success. Not willing to give up yet (what kind of directory admin would I be if I did?), but it looks like this is going to require some longer term effort than anticipated. The next avenue of attack will be to see if I can leverage an attribute we've got in each entry that identifies the geographic region it lives in (call it "destinationindicator" for purposes of discussion). This was implemented years ago to prevent our developers from relying on the structure of the DIT for that information. Anyway, thanks again for the insight.
-- Phil Lembo