I don't think that this is really possible without significant effort.

When we call into the TS API, we have to provide a compiler host, which for us gets created via
ts.createWatchCompilerHost.
This function accepts either a config file path on disk, or it accepts a config object, and an array of root filenames to seed the project from.

The significant effort would be us manually implementing a compiler host to work around this API limitation.
If this were added to TS itself, then sure we could add it in, but that then ties the feature (and thus your project) to a brand new version of TS.

or it accepts a config object, and an array of root filenames to seed the project from.

Wouldn't this solve the problem? Or am I misunderstanding something?

In XO, we have the config and TS file paths, just not the config file on disk.

Do you have a raw json file content or parsed one (an instance of ts.CompilerOptions)? If it's the first, such object can be parsed with ts.parseJsonConfigFileContent to get ts.CompilerOptions and fileNames, which can be passed to a second overload of ts.createWatchCompilerHost

Raw

XO makes its own calls into the ESLint api right?

If yes, then this might be a good use case for a more generic solution like in #1442

I'm hesitant to accept tsconfig via parserOptions, because it would be even more reliant upon the tsconfigRootDir option, which I know already causes problems for people.
I'm probably worrying about nothing though.

XO makes its own calls into the ESLint api right?

Yes, it uses ESLint's programmatic interface (CLIEngine).