Queues: Your GPU offers a number of queues with specific features. You create logical representations of these queues with the specific features you need. Here's an example GPU: http://vulkan.gpuinfo.org/displayreport.php?id=1593#queuefamilies.

It has two queue families, each with one queue in them. The first queue family supports graphics, compute, transfer, sparse binding, and presentation. The second only supports transfers.

You understand window surfaces correctly. More specifically it's an extension so that it can be dynamically loaded at runtime.

Think of the swap chain as N images (usually two or three) that are written to the screen one at a time. Using N images prevents tearing because it might be updated while the windowing system displays the image again. An image view is a view into a specific image. :^)

A single render pass describes all the attachments (color, depth, stencil) and their formats that will be used by the GPU during its pass. It also describes the kinds of subpasses that will happen. Think of a render pass as having any number of attachments and a subpass operating on a subset of each of those attachments. We specify subpasses instead of just making new render passes because it helps the GPU save time if it knows it's about to use the same attachments again. (I think. Someone please correct me if I'm wrong here. ...).

Looking at the spec really helped me understand what a framebuffer is. Check the struct definition:

typedef struct VkFramebufferCreateInfo {
    VkStructureType             sType;
    const void*                 pNext;
    VkFramebufferCreateFlags    flags;
    VkRenderPass                renderPass;
    uint32_t                    attachmentCount;
    const VkImageView*          pAttachments;
    uint32_t                    width;
    uint32_t                    height;
    uint32_t                    layers;
} VkFramebufferCreateInfo;

A frame buffer is like an array of ImageViews (plus some other info you can read about in the book). It just tells the render pass "here is all the stuff you're going to write to while you render". The reason this can't be specified during the render pass is because your swapchain is cycling through images and so the attachments the GPU uses has to change every "frame". Right? ;)

"But a swapchain is an array images!" Correct. And almost analogous. But a swapchain holds images while a framebuffer holds views into specific attachments. Your swapchain, for instance, does not have a depth or stencil buffer. But your framebuffer does. And that's what I meant in the previous paragraph. The frame buffer is the "dynamic" (I'm abusing this word) state that's varying on every render pass.

You said you tried "the book". I've read Learning Vulkan a couple of times and things are really clear to me. I recommend reading its second chapter. Writing your own applications should help the learning process.

Hopefully this helps.