I've been thinking about this for a couple of weeks. Short answer is, no. You can not strip out Torque's networking nor can you really "point" the Torque networking towards an Oracle system. There is no situation in which Torque networking code is actually unused.
Torque networking is by definition a connection between a Torque client and a Torque server. The structure is baked in one step below the top level of torque's game object class inheritance tree and forms the basis for all interactive and updatable game components. It is the mechanism used (among other important things) to update and synchronize a high-level object's tick-based mathematical simulation and framerate-based interpolation/rendering.
Objects are basically designed as two halves. Each half expected to operate in a specific space where the server side updates data as needed (and *only* as needed) and the client side uses that data to maintain a simulation's rendering and media output. A game object must have both to function. So there really is no such thing as a non-networked Torque game. What appears to be single-player is functionally just a networked game with a local client attached in which the server does not accept external connections. As far as game objects are concerned, the client/server interchange involved with keeping objects updated and rendering them is no different than if the client were attached over the internet.
Which gets to what you are trying to accomplish. As far as preventing people from connecting to future multiplayer servers through some sort of hypothetical script hack, it would simply take nulling out a couple of engine functions that handle finding and connecting to external servers. Likewise, the engine capacity to host multiplayer could be disabled in a similar fashion.
As for the Oracle thing ... what does the Oracle system do? What information does it provide/manage and what is the anticipated client update frequency? Are you planning on requiring the single-player version of the game to have a connection to the Oracle server?
Any way it goes, unless you want to rewrite pretty much the entire engine the Oracle server will need to update the Torque simulation somehow while still letting Torque networking do it's thing. I'd say maybe create a custom network link between Oracle and the Torque server to update the master simulation as desired. If real-time control of the sim is needed, latch it into the main loop and get an Oracle sync/update just before all the objects tick or something. In that case any changes as the Torque server interacts with Oracle that impact the visual sim would be seamlessly pushed through to the client(s) regardless if the client is local or remote.
Thing is, you're adding a ton of potential latency any way you do it. The more frequently Oracle updates Torque, the more latency will accumulate. For stuff that would only happen a few times per session - like saving/loading games, managing lobbies, etc. - the issue wouldn't be a big deal at all. For functionality that controls/impacts the sim in real-time, it seems like the issue could cascade pretty damn fast. Weather or not it is a good idea has a lot to do with which end of the spectrum your envisioned use sits on.
If you are dead-set on linking the technologies with a sub-second update interval, I'd recommend only considering it for a multi-player situation with Torque compiled into Linux alongside Oracle on a server so the link between the two can be accomplished via a local connection (or engineer with a seriously high-bandwidth physical pipe). For something like that, I honestly think performance might prove to be an interesting (but perhaps not insurmountable) challenge.