It does indeed seem like this information is not exposed in a data extension or public data view.
So by default, you cannot split like this. Einstein does not provide you a record by record view of the times it calculates at this time.
You would have to do an ex post analysis. It's less clean, but since you have no data available at the start, it's what we are left with. At least you would't even need to split for that. Just observe actual sendout times.
Assumption: Set the Einstein setting for "insufficient data" to "send immediately".
Send an email with STO, then look at sendout times the system tracks in _sent, or in a sendlog you set up. Now you can just compare opening or click rates of those whose sent date is leaning towards "immediately" vs. those who got delayed.
Hypothesis would be that you see the "delayed" group perform better.
Obvious problem: those whose "optimal sendout time" is the same as "immediately" blur the result somewhat.
Sending at a time that is as far away from what Einstein classifies as currently best would fix that, however, this in itself will of course skew your results, those badly timed emails would likely perform worse.
So better accept some blur than to knowingly skew.
If your whole plan is a sort of Proof Of Concept, I would go with this approach.
It would be good enough to see if Einstein STO absolutely DOESN'T work.
===
You could also engineer it more, and try and approximate it in two steps, but this will be much more effort, and isn't perfect either:
If you anyway want to lead "unclassified" data down a separate path, you would have to prepare a sort of trial run with a very similar approach:
i.e. "observe an STO sendout closely, then split a second sendout, based on the observation" - the sendout times of the "observation" sendout would give you a snapshot of when mails were actually sent to which user.
This will also not be ultra clean as there is a time lag between your observation sendout and the "real" sendout, during which recipients who had no optimal time in the observation sendout get their time calculated.
At any rate: For this you would need a sendout to all your addresses using STO, say in an optimization timeframe of 24 hours. This needs to be more or less shortly before your real sendout, so the data doesn't change too much.
Again, Set the Einstein setting for "insufficient data" to "send immediately".
Send an email that includes a sendlog so that you track the sendout time, or use the _sent data view.
In your sendlog (or data view extract), you should see roundabout 69k with a sendout close to the planned timeslot (they were "sent immediately", as fast as journey builder could process), and a lot of others at a different time - those were held back because Einstein knows their "optimal time".
Put their Subscriber Keys into a data extension as "STO_optimized; true / false" records, connect the DE to the Contact Model, insert a decision split based on that DE.
Yes, this has business implications and you would need to fit it somehow in your sendout plans. Yes, it is only an approximation, and it's a one time snapshot.
And the obvious problem of "people whose optimal date is close to immediately" remains. So really... for a POC, just try STO and look at the results after the fact.
