No problem.

FreeSWITCH has several tools to assist with this, most notably playAndGetDigits
The dialplan app is doc'd here: http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_play_and_get_digits
The IVR-ish way is doc'd here: http://wiki.freeswitch.org/wiki/IVR
The mod_lua docs have good info about using it from calling lua from the dialplan: http://wiki.freeswitch.org/wiki/Mod_lua#session:playAndGetDigits
 

I think you might be suffering from information overload. :)
The event socket works in two methods: inbound and outbound. We have been throwing around concepts that apply to both without really doing a lot of qualifying.

In most cases we are talking about inbound event socket where your server establishes a connection to FreeSWITCH. To see more about the outbound event socket look at this:
http://wiki.freeswitch.org/wiki/Event_socket_outbound
Essentially you can create a program/script that sits and listens on a TCP port for connections from FS. When your program gets a connection then it can control the call leg via event socket commands. In the outbound event socket paradigm your program sees *ONLY* the events related to your specific call leg. When the call ends, so does your socket connection. You can use outbound socket for call control if you want to do so, however it is by no means required.

As far as inbound event socket goes, the official docs start here:
http://wiki.freeswitch.org/wiki/Event_socket

The classic example of an event socket application is one you may not expect: fs_cli
If you REALLY want to see what the event socket looks like then fire up fs_cli and do this:
/log 0
/events plain all

At that point your terminal is a raw event socket client. :) You can send commands and see all the crazy stuff that comes across via events. Once you get a feel for the events that come and go then you can think about how to attack your problem.

In your specific question about using the uuid to figure out what to do with the call... yes, you *could* do that if you wanted to. You could also have the call controlled by the dialplan. For example, you originate a call and drop it into the dialplan and let the dialplan handle it. You will still get events about that channel, for examples when the caller changes states, or even DTMFs, etc. (if you want to see them) but the call is being controlled by the dialplan itself so that your program doesn't have to control it. You could then have, as part of your event loop, a "show channels" (or "show channels as xml") happen every x seconds and just parse it to see what's happening on your calls. If you're a real stud programmer you could have your script maintain a state machine for each call and use the incoming events from the event socket to update your call states.

Are you sure you still want to do this? :)
-MC