es geht technisch - ist aber nach meiner Einschätzung für diesen Anwendungsfall nicht bezahlbar.
Was dann nix anderes als ein Proxy ist. Wie ich oben schon sagte.
Und freilich gibts da auch OpenSource sowie kostenfreie Lösungen. Allen vorran die Sophos UTM Appliance respektive als VM erhältliche Maschine, die im Home Bereich kostenfrei zu betreiben ist und derartige Funktionen bietet.

Nur der Aufwand steht in keinem Verhältnis, selbst wenn das ganze effektiv "nix" kostet für die Anschaffung des Produktes selbst.
Origin.exe --> nutze WAN1 über die Telekom DSL Leitung
Steam.exe --> nutze WAN1 über die Telekom DSL Leitung
Rest --> nutze WAN2 über die Vodafone LTE Leitung
Das hat doch mit Routing eigentlich nix zu tun? Oder steh ich fürchterlich auf dem Schlauch?
Ja, stehst du

Denn wie oben schon gesagt, das Internet läuft nicht so, wie du es dir da denkst.
Als Hintergrund empfehle ich (bei Interesse an der Materie) sich mit dem Routing bzw. allgemein mit Netzwerken auseinander zu setzen.
Um es eher kurz zusammen zu fassen.
Es ist ziemlich egal, welche Anwendung da agiert. Denn die Anwendung geht bildlich gesehen zu deinem Betriebssystem und sagt, löse mir mal bitte den und den DNS Namen auf. Bspw. steampowered.com. Du bekommst also vom DNS Server eine IP für diese Domain zurück. Mit dieser IP prüft dein Rechner, befindet sich die IP in meinem lokalen Netz, dann kann er sie direkt erreichen. Oder befindet sie sich außerhalb meines lokalen Netzes, dann schicke ich das Paket zu meinem default Gateway (sofern kein genauerer Routingweg definiert wurde). Und hier liegt genau das Problem.
Das ganze Konstrukt baut darauf auf, das die Wege "genau" definiert sind. Du kannst bspw. die IP 8.8.8.8 in einem statischen Routeneintrag zu einem anderen Gateway/Router schicken wie die 8.8.4.4. Aber um das zu tun, musst du eben wissen, was für IPs du da ansprichst. Bei externen Anwendungen, wie eben Steam und Co. sind das hunderte, eher tausende IPs, die irgendwo wild in der Welt rumstehen und die sich dazu noch alle Nase lang ändern können. Dazu kommt, das ist nur die halbe Miete. Denn die Plattform Steam/Origin/UPlay bspw. ist eben nur die Platform für die Games. Dort lädst du allein den Content für die Games. Die Spiele selbst sprechen wieder völlig andere Server an... Da kommen in Summe zentausende verschiedene IPs zusammen. Das händelst du nicht von der Clientseite aus.

Heist unterm Strich, wenn du eine Möglichkeit findest, dir aktuelle dynamische Listen zu besorgen, dann lassen sich da auch Mittel und Wege finden, derartige Sachen über mehrere WAN Verbindungen zu sharen. Ohne das, geht es bestenfalls über einen Proxy. Denn werden (wie im Heimbereich üblich) keine genaueren Routen definiert, wird ausnahmslos alles, was nicht im lokalen Netz des PCs ist, zum default Gateway geschickt. Und das default Gateway ist genau ein einziges Gerät. Eben dein Router. Hast du zwei davon, fehlt wie oben angesprochen schlicht die Möglichkeit, das Ganze so zu verteilen, wie du es gern hättest. Diese Arbeit müsste dann ein Proxy für dich übernehmen, einfach, weil der Proxy selbst eine Ebene weiter oben ansetzt und das ganze auf Domainlevel abhändeln kann. Da kannst du dann jegliche Pakete, die für steampowered.com sind, über eine andere WAN Anbindung schicken zum Beispiel. Nur bringt das potentiell halt auch völlig andere Probleme mit ins Haus. Denn wenn dir da dochmal irgendwas durchrutscht in der Erkennung, bspw. weil ein Server von Steam nicht mit der Domain steampowered.com angesprochen wird, sondern keine Ahnung, nur steam.com nutzt, würde dieses Paket dann nicht über die andere Leitung geschickt werden. Damit agierst du Internetseitig über zwei verschiedene public IPs. Das führt zu Problemen und geht oftmals völlig in die Hose, da der Server auf der Gegenstelle (gerade bei HTTPS) empfindlich auf source IP Änderungen reagiert. -> Den Umstand kennt denke ich fast jeder, wenn sich die DSL IP des Anschlusses ändert, werden offene Verbindungen idR nicht selbstständig wieder aufgebaut. Gerade Sachen mit vorheriger Anmeldung fallen da idR hinten runter und bedürfen einer erneuten Anmeldung.