You can actually have as many sockets as your OS can support. Sending a message to a public Server is very easy over UDP, you just send a packet there and pray. It is so because you have the IP address of your server. However, sending an UDP packet from the Server back to the Client won't work in the majority of cases, because most users are behind some kind of NAT. There are technique how to "get to" the user called UDP hole punching. It works in a similar fashion like TCP connection. I should mention that it is a bit complicated to implement and is not a common practice (I think).
I think the most straightforward first step of getting some benefits from UDP would be adding Client -> Server "unimportant" event updates. TCP would remain for main connection and the reliable updates, such as the Server game state stream.
For the Server, you can use any port that is not already used. Servers usually are not behind NAT, or ports can be easily forwarded to them. If you are initiating connection over the TCP or only sending data over the UDP you can let the OS to choose your outgoing port, so clients are not bothered by that.
Now, weather it would be a good idea to have UDP: it depends on a game. How many trivial updates do you actually have? For example, in shooters the direction player currently looks at is usually considered as trivial data and it is sent to the server over UDP.