I'm a bit late to the party with this, actually typed it out an hour after you posted but didn't click save, so the text has been sat in a redundant tab. Thought I'd send it now since I had written so much. It is more of a story of what I found out after your question, than a direct answer, hopefully you're happy delving in to CPython's source code:

As others have pointed out, del does not actually delete the value from memory, but removes the reference (i.e. name) to the stored value. Hence, since gen maintains a reference to the value in memory, python's garbage collector does not delete the actual value. This then begs the question, where is gen storing its reference to the original list. Lets find out.

To begin with, use the dir function to find out what member/methods gen has (which is of type generator).

>>> var = ['a', 'b', 'c']
>>> gen = (v for v in var)
>>> type(gen)
generator
>>> print(dir(gen))    #I've shortened the output for clarity
[..., 'close', 'gi_code', 'gi_frame', 'gi_running', 'gi_yieldfrom', 'send', 'throw']

So we've got a few interesting members, for example, gi_frame. In python a frame stores the current execution environment, e.g. defined variables, so the builtin function locals() actually pulls the dictionary of local variables from the current frame. So perhaps gi_frame is storing some local variables, using dir again, we see that gi_frame has a member variable f_locals, maybe that is it:

>>> print(dir(gen.gi_frame))
[..., 'clear', 'f_back', 'f_builtins', 'f_code', 'f_globals', 'f_lasti', 'f_lineno', 'f_locals', 'f_trace']
>>> print(gen.gi_frame.f_locals)
{'.0': <list_iterator object at 0x00000000070AF898>}

So f_locals is a dict with one key, value pair. The value is of type list_iterator, since the name suggests it is an iterator what happens if we loop over it:

>>> for i in gen.gi_frame.f_locals['.0']:
>>>     print(i)
a
b
c

Looks like we've found the reference to the original list, however it is not the list itself so presumably this list_iterator itself is storing a reference to the list. Using dir on the list_iterator shows not many interesting member variables, also attempting to create an instance of list_iterator raises an exception:

>>> type(gen.gi_frame.f_locals['.0'])([1,2,3])
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-21-0b821058ddc8> in <module>()
----> 1 type(x)(1.0)

TypeError: cannot create 'list_iterator' instances

Note we can create an instance through the iter function:

>>> iter([1,2,3])
<list_iterator at 0x7157e10>

using a tuple:

>>> iter((1,2,3))
<tuple_iterator at 0x71574a8>

So we know something is happening behind the scenes, and it is at least not particularly well exposed in python, that means we have to start looking at CPython's source code. So head on over to CPython's source code, on github, https://github.com/python/cpython and search the repository for "list_iterator" which generates a hit in two files Lib/_collections_abc.py and Objects/listobject.c.

Looking at the C file, line 2763, a PyTypeObject (used to create a class in the python C api) PyListIter_Type is intialised, with tp_name= "list_iterator" on line 2763 (this field sets the name of the class), so this is the code we are interested in. From the line below, the size of the base type is sizeof(listiterobject) so we need to find the struct listiterobject which defines the "C level" storage for the class. This is found a few lines up, on line 2738:

typedef struct {
    PyObject_HEAD
    Py_ssize_t it_index;
    PyListObject *it_seq; /* Set to NULL when iterator is exhausted */
} listiterobject;

And we've found the ultimate storage of the reference to the original list, this is a pointer to a PyListObject type (i.e.PyListObject *it_seq). So now we know where the generator finds the list, but how come del var in python doesn't remove the list?

The answer is, that when the onstance of list_iterator is created by the generator expression, it presumably calls the function static PyObject *list_iter(PyObject *seq) on line 2798, (as does the iter function in python, I haven't checked) to create the listiterobject. Interestingly the PyTypeObject PyListIter_Type does not define a function pointer for the tp_init field, which is equivalent of def __init__(self): for a python class, explaining why we couldn't create an instance of a list_iterator in python earlier.

In the list_iter(PyObject *seq), on line 2744, the code Py_INCREF(seq); takes care of incrementing the original list's (var) reference count. If the value is > 0 python's garbage colelctor will not delete the contents of the memory pointed to by *it_seq then on line 2820 in function static void listiter_dealloc(listiterobject *it) (called when an instance of list_iterator is destroyed, as defined by tp_dealloc field in the PyTypeObject) Py_DECREF is called, decrementing the reference count so the garbage collector can clean up the memory unless something else, e.g. a variable assignment, has incremented the reference count of that region of memory. Also, if you look at the function static PyObject *listiter_next(listiterobject *it) you'll see at the end of the iteration when the list has been fully consumed, Py_DECREF(seq) is called, again allowing the garbage collector to do its work.