If you're running your own network, you could initialise every node with a randomised Corda identity that gives away nothing about who they are, e.g. is a UUID. Then you implement your own protocol (or flow) to resolve user input to that randomised identity. The resolution must return zero results if the user input is even slightly wrong, for the reasons discussed above, so your own notion of business identity would need to be constructed with that in mind (e.g. check digits, if using numbers).
The advantage of this approach is you don't need to modify Corda. The disadvantage is nodes can see how many participants exist in the network and their IP addresses, but wouldn't know who owns them. The mere existence of an IP address in the system may still reveal too much information for you though.
The problem with wanting to be compatible with corporate firewalls whilst still hiding possible IP addresses is, as JC observes, that some companies want to whitelist IP addresses in advance. This isn't compatible with being peer to peer and also not knowing who your peers are.
Another way to do it is as above, but with the addition of a VPN. Everyone VPNs to a central point you administer and is allocated an internal IP address, so IP ownership is secret and corporate firewalls can whitelist the VPN endpoints. The network map would still reveal the number of participants in the system but nothing else. You can fill it with dummy entries if you want to hide the size of the system.
At this point though, it may not be entirely clear what balance of power you're wanting to achieve. The central party would control all user interactions, would see all business relationships and could probably change node's public keys to impersonate them without anyone noticing. Availability would be identical to a centralised system. What powers do you want users to have in your system? Perhaps there's a more direct way to achieve it.