Setup Wireguard on your server as though everything were normal. However, on the server, run this command (as a service):
udptunnel -s 443 127.0.0.1/51820
Then on your client run:
udptunnel -c [SERVER-ADDR]/443 127.0.0.1 51818
In the Client's Wireguard Config, where you would normally specify the server's address / port. Instead specify 127.0.0.1 51818. Finished!
Don't forget to open the firewall on the server's port 443!
Setting up udptunnel as a systemd service to auto start / restart only involves writing two short files! Wireguard uses a standard service file as well so you can simply require the udptunnel service as a prerequisite!
Personally, I find this style of combining simple components much more satisfying (and secure!) than the gargantuan complexity of OpenVPN/IPSec! Wireguard's simplicity means it is easy to have a mental model around how it functions and how it can be composed!
(not that it matters when you're trying to tunnel out of university network, but something to keep in mind, especially on lossy connections)
I've sometimes contemplated just faking the TCP protocol entirely. Do the TCP handshake, then send "TCP packets" but interpret each payload as a datagram, acknowledge everything up to the latest sequence number regardless of whether any of them were lost and don't bother with any flow control or retransmissions.
It's a terrible hack but it would probably work at least some of the time.
Your suggestion is how some "WAN optimisation" network middleboxes work (transparently terminating the TCP in the middlebox itself). To do that with Wireguard you'd have to implement that in the Linux kernel.
application data in
IP+<L4 protocol> in
IP+UDP Tunnel (Wireguard) in
So securing the component mess and header bloat is becoming as bad as OpenVPN/IPSec which you abhorred. Still probably faster than OpenVPN though as that implementation is amazingly bad.
Wireguard authenticates (or drops) any packets forwarded by udptunnel. Once a packet leaves the Wireguard interface the attacker (or anyone else) can transform it however they like without impacting security properties.
This config does allow the attacker to make a TCP handshake to the server, but the data they send over the TCP wrapped connection could have equally been sent to the UDP port Wireguard is listening on.
Disclaimer: This of course assumes both Wireguard and udptunnel have no remote code exploits or other implementation errors. However, as we discussed, this is a much safer assumption than OpenVPN...
So it's not a security hole, but it is slightly less secure.