I would give an answer of "no, but it is remarkably similar."
Here's some history and a largely complete explanation.
Circuits 101
Information networks can route traffic, basically, in terms of circuit switching or in terms of packet switching. Circuit switching offers many more guarantees than packet switching, but this comes at a cost, and so circuit switched networks can't degrade gracefully. The classic circuit-switched network is the PSTN, and a virtual circuit would be something like a DS0 on the PSTN.
A DS0 basically works as part of a bundle of connections, usually in a DS1. In a DS1, you will have a bundle of DS0's which are transmitted together, frame-by frame in time-division manner, so each DS0 is guaranteed a specific bandwidth, timeliness, etc. by the underlying network transport.
Another way to look at this is that a physical circuit would be something like a cat6 cable running between two terminals. You can send data back and forth over the wires at guaranteed speeds, and no other communications are going to interfere with that. Indeed the early telephone networks worked by connecting physical circuits (that is copper wires) using manual or electromechanical switches. As this was computerized, the circuits were virtualized and digital (as opposed to analog) information was sent down wires on a time division basis again with a circuit reserving a slot in the time division schedule.
What this means is that circuit switching is more about bandwidth reservation than it is about routing. The former leads to the latter. I.e. a circuit reserves bandwidth for the entire connection.
Why TCP Connections are not Virtual Circuits
TCP/IP is fully packet-switched. It makes no provisions for virtual circuits. This is why things like QoS are often necessary when trunking VOIP (a virtual circuit has built-in QoS guarantees). You have no guarantee that all packets will be routed alike. They may not come through in the same order. They may not come through in a timely manner (from a connection-oriented perspective). So you can't really build virtual circuits per se on top of a packet switched protocol like IP.
TCP comes somewhat close and in fact can work as a somewhat imperfect substitute. It offers as many of the guarantees as it can. This is why, when implemented on TCP/IP, H.323 uses TCP connections instead of the virtual circuits the protocol prefers.
But TCP connections still aren't circuits, because they don't reserve bandwidth during connection on every switch between the two nodes.
Of course TCP connections are more than just datagrams. They include routing information (as does UDP) but they also include the accounting information necessary to reconstruct the stream on the other side in order.
The Answer
Both TCP and UDP are datagram protocols. They send a packet of data with routing information to routers with none of the guarantees of that a circuit offers. TCP offers a subset of guarantees on the end points of what a circuit would offer by adding accounting information to allow the end points to handle errors and a series of data in order, but it is only a subset. Of datagram protocols, TCP is the closest thing one will find to a virtual circuit but it is still conceptually and operationally very different.
The roots of the two technologies just are not really related.
When Bob Metcalfe, et al. were creating ethernet, they were not working with Vint Cerf, et al. who were creating IP. These were two completely separate efforts. When ethernet was created, it was not at all clear that IP would become dominant, and ethernet was just one of several LAN technologies that was vying for attention. IP didn't get on ethernet for a relatively long period of time because IP was originally connecting universities across the country using WAN technologies.
Eventually, the market forces preferred the two technologies, and they ended up the dominant technologies in their respective niches, but, although they were both conceived (1970s) and born around the same time period (ethernet in 1980, and RFC 791 in 1981), they actually didn't have much to do with each other until the 1990s, and they are still maintained by completely separate standards organizations.
Best Answer
This is a case of, "in theory there is no difference between theory and practice, ..."
Usually, applications interact with operating system's network stack using an abstraction, called sockets. Sockets, which is also some sort of object that is maintained inside the operating systems, contain necessary information.
a UDP header must contain these values. Your OS (or implementation of network stack) can choose when to set these values.
I frankly speaking do not think that it works like described, and instead OS requires you to specify local address for a socket, before you can send packet through the socket.
But here is a plausible explanation, why it can work like this. Source addres is determined by routing function. You can have several network interfaces, each of which has different source address. Then your host can be configured to send packets to one set of destinations to one address and another set of destinations to another address. Then, you can't really set source address, before the decision of routing is done. In this case network layer will have to set the values in the headers.
update actually, sorry, that quote does not make sense.
ports only exist at transport layer, so transport layer definitelly does not pass destination port to the network layer. it passes destination (and potentially source) ip address, but not port.
a source port is assigned before a packet can be sent. if the source port is not specified by an application, OS will just select one and put it into the header. This actually works the same with TCP. When you initiate a connection, you specify destination port, and source port is randomly selected for you.
end update
Operating system/network stack has to provide you with this information, and how it does this depends on the socket API. Here is a link to linux man page for recvfrom, check the second function.
In general, layers communicate with each other, and when a lower layer strips packet header, it can still pass all the necessary information from that header to the upper layer. How this is done, is specific to how the network stack in question is implemented. But it has to be done and it can't work otherwise.