Not really an answer, I just can't comment...
Did you evaluate the option to use simple Arduino/AVR? With Atmega128 TQFP64 you should be able to get 26ish software serials, the hardware UARTs can go as fast as 2Mbps (to connect to PC host), Atmega128 has 2.
There is also STM32F103 series ARM with 72MHz clock.
On the PC host side, if you really need 26 separate COMs, there is possibility to use virtual COM ports...some software will be needed to "aggregate" data of these 26 ports into real 1. Or edit your PC software. Creating some custom protocol (similar to Modbus) to address each serial port shouldn't be hard. Same on MCU side.
If they are distinct USB peripherals at least one of which supports mode switch functionality then yes. This is in fact fairly common on dual USB microcontrollers and tablet-type SoC's. Your diagram seems to show such a situation, with one OTG capable dual-role port directly accessible, and a second port setup for host use with a built in hub.
A USB hub tends to be entirely incompatible with usage of any of its ports as a USB device, as operating the USB engine in device mode would be incompatible with operating it in host mode to talk to the hub.
Probably the closest you could come to that would be using a USB data interchange cable plugged into one port of an onboard hub. A data interchange cable is a sort of dual-ended USB device - but one that is generally limited to a particular scheme of data transfer. Of course once you have that pipe supported at both ends, you can push fairy arbitrary data down it.
Theoretically it might be possible to design a hub chip with a single "passthrough" port that could be (while disabling all other ports) reversed to operate as a device and forward data to the SoC's USB interface operating in device mode, but this seems unlikely as a product, as most of the devices where operation as a device is supported don't have space for the connectors from an internal hub anyway. Ultimately in most embedded/dev board settings, the dual USB peripheral on chip approach is preferable to a single port permanently connected to an on-board hub.
Of course in the end USB is not just about hardware, but also about driver stacks and system services, user-mode APIs, etc. There has definitely been hardware that shipped with capabilities not reflect in the software, and it is theoretically possible that a software stack could enforce some kind of limit where both ports would have to be in the same mode. But that doesn't seem too common. An inability to switch modes at all though often is - the mode determination is usually ultimately made by software, which may or may not consider or honor a hardware mode detect input pin.
If you read the document that you linked in, you'll find that the ICH6 itself does not supply the current for the USB port at all, as there's no pin for that on the chip. Instead, an external circuit is used for that. This is a pretty standard way to implement power to USB host ports.
There are several ways to implement the USB power supply, the simplest way is to connect it directly or through a PTC to +5V, like in Raspberry Pi:
This way you may draw from the USB port as much as the power supply (or the PTC) allows, and a short circuit will likely disrupt the operation of the host.
Or a special USB load switch IC may be used, which can limit the current to some fixed or configurable value and/or may be used to completely switch off the power to that port, like the SY6280 in Marsboard:
There are also USB load switch ICs that are able to indicate overcurrent situation back to the host, like the LM3526 in an LPC17xx board:
So, how much current you may draw from your USB ports without getting into trouble, and what happens if you draw too much, totally depends on the circuit used to power your ports (and sometimes the software configuration as well), outside your SouthBridge. You may examine your board and try to trace the USB power lines to see what ICs are there (they are usually very close to connectors), and then reading the data sheets might give you some clue.