You are correct re: UDP. You're going to have to implement your own protocol (using an HMAC to guarantee authenticity, etc) to prevent spoofing of UDP-based protocols.
TCP sequence number prediction was a viable attack in the past. Some operating systems made very poor choices in the initial sequence number that allowed these attacks. The attacker's connection is one way, since the machine with the real source address of the spoofed packets will be receiving the stream being sent by the host being attacked, but if you don't have need of anything the remote host might be sending (i.e. you're performing an attack that involves writing only to the remote host) then the lack of a receive channel back from the remote host is irrelevant.
An interesting paper with some very phase-space plots of TCP initial sequence number analysis is available here: http://lcamtuf.coredump.cx/oldtcp/tcpseq.html Alas, it's Windows 2000 and Linux 2.2-era data. (There are some cool pictures, though!)
I'm not aware, off the top of my head, of any current papers examining modern operating system TCP initial sequence number generation, but they're probably out there. The trend in the industry was moving toward stronger algorithms, and my feeling is that though there are probably some embededded devices out there ripe for attack the majority of mainstream operating systems are now using algorithms that have sufficient randomness so as to prevent an seqence number prediction attacks from being viable.
If your attacker can intercept your TCP stream all of the randomness on initial sequence numbers in the world won't help you. Encrypt your traffic (wrap it in SSL, IPSEC, etc) and you've solved that problem, too. (Then you can worry about key distribution, host authentication, etc... Don't worry-- there are more problem where those came from. We'll make some more and never run out... >smile<)