<p>If I have a separate system with its own concept of users and presence, what is the most appropriate architecture for creating a bridge to an XMPP server network?  As far as I can tell there are three primary ways:</p>

<ol>
<li><p>Act as a server.  This creates one touchpoint, but I fear it has implications for compatibility, and potentially creates complexity in my system for emulating a server.</p></li>
<li><p>Act as a clients.  This seems to imply that I need one connection per user in my system, which just isn't going to scale well.</p></li>
<li><p>I've heard of an XMPP gateway protocol, but it's unclear if this is any better than the client solution.  I also can't tell if this is standard or not.</p></li>
</ol>

<p>Any suggestions or tradeoffs would be appreciated.  For example, would any of these solutions require running code inside the target XMPP server (not likely something I can do).</p>

The XMPP gateway protocol you've heard of is most likely to do with transports.  A transport is a server that connects to both a XMPP server and a non-XMPP server.  By running a transport, I can use my Jabber client to talk to someone using, say, MSN Messenger.
A transport typically connects once to the remote network for each JID that it sees as online.  That is, it's your option 2 in reverse.  This is because there is no special relationship between the transport and the non-XMPP network; the transport is simply acting as a bunch of regular clients.  For this to work, XMPP clients must first register with the transport, giving login credentials for the remote network, and allowing the transport to view their presence.
The only reason this has a chance of scaling better is that there can be many transports for the same remote network.  For example, my Jabber server could run a transport to MSN, another Jabber server could run another one, and so on, each one providing connections for a different subset of XMPP users.  While this spreads out the load on the Jabber side, and load balancing on your system may spread out the load as well, it still requires many connections between the two systems.
In your case, because (I assume) the non-XMPP side of things is cooperating, putting a XMPP server interface on the non-XMPP server is likely your best bet.  That server interface is best suited for managing the mapping between XMPP JIDs and how that JID will appear on its own network, rather than forcing XMPP users to register and so on.
In case you haven't seen these, you might find them useful:
http://www.jabber.org/jabber-for-geeks/technology-overview
http://www.xmpp.org/protocols/
http://www.xmpp.org/extensions/
Hope that helps.