I can imagine being able to do this when you control both sides by letting one type of data flow over one IP and the other over a different one with different peerings. But I wonder whether this is generally available.
I expect some ISPs will end up using differential routing over Starlink and fiber. They could have the routers on each end automatically switch large one-way TCP transfers from the Starlink connection to the fiber connection after the first 2MB.
They could even make the transition smooth, by buffering data transferred over Starlink and slowly adding delay to match the delay of the fiber connection. This would require some RAM, but only during the transition period for each TCP session. The client would see the throughput go down during the transition period.
If the remote server could increase the data rate, then the ISP could perform the transition with no drop in throughput seen by the client. The sending router would send fake ACKs to the server to get it to send data faster. The sending router would send the burst of data through the fiber link and also buffer it and send it through Starlink at the original rate. Once the receiving router is receiving the same data at the same time over both the fiber link and Starlink, the sending router can stop sending over Starlink. The client's TCP ACK packets would continue to flow over Starlink.
You would probably have to configure your own routing table to direct traffic for each application through the appropriate link, but that's completely doable as long as you can write rules to distinguish the packets (for example based on destination).
I can imagine that it would be beneficial for the internet experience if we could segregate low latency traffic (human/hft) traffic from hulk traffic such as video. Although this goes against net neutrality I suppose.