If I can attempt to summarise; with ULV you tell it that you have X items to show in the list. You can add them all at once, or individually. Either way, each item has an id. But they're not displayed right away - it just knows that, for instance, item id 1 is at position 1, item id 2 is at position 2.
When the list is actually displayed, the ULV calls a sub, indicating the id and the position of of a specific item; it does this for each one that's visible. The sub can then do things, like query a database, or get items from a list, based on the id and/or position, and fills the layout for that item with the results.
When something is clicked in the list, again, a sub gets the id and position, and can handle them appropriately, deciding which bit of the underlying data needs to be updated.
You can use a combination of sources of information for each part; for instance, in my app, I create a list of people who are online using ULV; that's based on a list returned from the server. When the information is displayed, when I fill the layout, some of the information comes from the list (based on the ID, which I used as an index into the list), while other bits come from a database query, using the ID to look information up.
I found ULV very flexible - but you have to get your head around the fact that it works in a slightly different way to other lists, in terms of the initial loading. When it comes to the clicking on an entry, it's not really so different.
Biggest difference could perhaps be put like this:
In a CustomListView, etc, you usually create each element at the start, processing the data to build all the entries at the same time
In a ULV, you just associate your data (by ID) with the list at the start; each entry is built only when it's actually displayed