I know this already has an answer accepted but here is perhaps some additional information:
Is Working Set (Mem) exactly a size of process memory on RAM?
No. It is the subset of the process's virtual address space that is "resident", or "present" in the terms of the Intel page table format, meaning that it can be accessed without incurring a page fault. It is a somewhat misleading number for a variety of reasons, chiefly that a) it includes some RAM that is shared with other processes - mostly those that are using some of the same code, like the code from common libraries, and these shared pages are counted in the "working set" of all processes in which they're resident. So if you add up all the "working set" sizes you get a number larger than the true amount used. b) Also, some RAM that was recently lost from the process working set due to page replacement will likely still be on the system's Standby page list, and if so, accessing it will incur a page fault, but not a hard page fault. So that is RAM that contains information from the process that the process may use again - but it isn't counted in the working set.
Is Paged Pool (VirtMem) exactly a size of process memory on swap file?
No. Paged pool is a particular type of kernel-space memory heap. The "Paged Pool" column in the processes display in Task Manager is an indication of how much paged pool has been allocated to support that process's activity.
Is total process memory (address space usage) equal to sum of Mem and VirtMem?
I don't know what you mean by "Mem", but if you mean any count of physical memory allocation, then no. You can'd add physical and virtual memory sizes together and come up with anything sensible. The physical memory used by a process is, rather, a subset of its virtual address space.
Windows has confused this issue through confusing, inconsistent, and changing terminology. In the screen cap you gave, for example, the first four "Memory - " counters are physical (RAM), "Commit size" and "paged pool" are both virtual, and "non-paged pool" which is, like paged pool, a kernel-space heap, but is never paged) is both the virtual and physical size of the allocation.
And a question you didn't ask:
Why is memory management so complicated?
Because it performs a lot better this way than simpler systems have in the past. Sorry about that.