So you know how you can plug two switches into each other and make essentially one larger switch?
Now take it in the opposite direction, break a 48-port switch in half and make two different 24-port switches. Those are, in this analogy, different LAN's.
When you do this "virtually" (eg, in configuration) you make VLAN's. That's it, that all there is to it. You make a bunch of smaller switches out of one larger switch.
So when you make these smaller switches, you have to number them. Those numbers are from 0 to 4095. 0 and 4095 are reserved, and in many cases so are 1002-1005, so 1-1001 and 1006-4094 are available for your mini-LAN's.
From there, you get to realize that you don't exactly have to break it in half, you can break it into as many LAN's as the device supports (maximum number of VLAN's), and the ports don't have to be contiguous--eg you don't have to put port 1-10 in one LAN; you can put ports 2, 14, 16, and 48 in a LAN. That's it.
Ok, so say you have two floors each floor having half of it's offices in different departments--sales and accounting. Each half of each floor has it's own switch, and you have a connection from the sales switch on floor 1 to the sales switch on floor 2 (and the same for the accounting switches). When somebody moves offices, you have to go physically move an ethernet cable from the sales switch to the accounting switch or vice versa.
VLAN's allow you to solve this problem. You simply put one switch on each floor, configure your sales and accounting VLAN's. When somebody moves, you simply change which VLAN their port belongs to.
Now you want to connect those two switches together. You could run a connection from the sales side of switch A to the sales side of switch B, and a second connection from the accounting side of switch A to the accounting side of switch B (you can actually do this), but what if there were a way to simply mark traffic traveling between the two big switches with which vlan they belong to?
Enter VLAN tagging. Exactly what happens is you just tell both switches that the port connecting them contains multiple VLANS, what those VLAN's' numbers are, and you're done. This is called a "trunk port" (in Cisco parlance).
So in the past, if you wanted to keep accounting and sales separate, you'd need two switches per floor, and a link between each departments' respective switches. Now you can do it with one piece of equipment per floor, and a single link between them. This becomes important when you have dozens of switches and dozens of VLAN's.
Now, why would you want to do this? Mostly policy and to reduce broadcast chatter in huge networks. There are a bunch of other reasons, but it's not worth getting into right now.
Now you need to put a router on each LAN and provide internet. You could buy two routers and two internet connections, plug one each into each of your LAN's and be done. Or you could buy a router with 3 ports (one for each LAN plus an internet connection), connect it to both LAN's and the internet, configure it up and your golden. But why couldn't you send the same marking that you're using between your switches to your router and conserve a port? You can. Routers support tagged traffic. Only thing you have to worry about at this point is that each of your (V)LAN's has separate IP address space so that the router can differentiate between the two. So you configure virtual inverfaces on your router for each lan, tell whichever switch you connect your router to that it's going to get multiple LAN's on that connection (and tell the switch to send them) and you're golden.
So now you have your switches, router, etc. Interesting part here is that you can filter traffic between each LAN. Say you don't want accounting to connect to sales' printers. No problem, filter it.
Say you've got a dozen switches in a large enterprise or campus environment and someone 3 blocks away gets moved from accounting to sales? No problem. If you're switches and trunk ports are properly configured, you simply change Suzie's port from one vlan to the other and she's now on that LAN.
In good switches, every frame has a vlan tag whether you tell it to or not. By default, out of the box, every port is on VLAN 1. If you make VLAN 2, and assign ports to it, you've got another separate LAN. Everything moving through the switch internally has a VLAN tag on it, it just knows to add them coming in and strip them going out.
Now, speaking of trunk ports, here's another useful scenario. Say you have a server that needs to provide services to more than one LAN. You can configure virtual interfaces on it and give it IP's in each LAN, tell the switch to send the relevant LAN's to it and you've got it. This is close to one of the best arguments you can make for VLAN's: Often, services (Window's networking comes to mind) find resources via broadcast frames. This allows you to segregate your network so that those broadcast frames don't go everywhere, with the option of allowing multiple vlan's to a device if it (or you) needs them.
Access points are another good place for them. Say there are different policies for each department and they all want wireless. You configure multiple SSID's on your AP and trunk it to your switches and you solve the wifi problem with a single access point.
Want a way to automatically tell all you switches about a new VLAN? That's called VTP (in Cisco). You configure the vlan on the master switch, every other switch learns about it.
So now you've got all this traffic between your VLANs going to a router--and in some cases, it's just a router with a single connection to the switch, called a "router-on-a-stick". But what if you could move that forwarding down to the switch?
That's called layer-3 switching, and enter SVI's. For each vlan, you configure an IP on a Switch Virtual Interface, and then the switch can control the routing between the two LAN's--and, hardware supporting, you can do your filtering there too.
So a port on a single vlan is called an "access port". The switch knows to strip the vlan tag going out, and add a vlan tag going it.
Also, on a trunk port, there's a concept of a "native VLAN" which tells the switch which VLAN any untagged frames should belong to, and to strip the tag off of frames that belong to the native VLAN. You don't actually have to strip the tags from any VLAN's, but you do have to tell the switch what to do with an untagged frame it receives.
Try this one: Say you want to treat your VoIP traffic differently than your bulk data traffic. So you put your VoIP devices on vlan 2, and make all your ports trunk ports, with VLAN 2 tagged an 1 the native (stripped) VLAN. Someone can come plug in a laptop and they'll end up on VLAN 1 (because the laptop doesn't understand the VLAN tags) but if you plug a properly configured phone (i.e. to tag for VLAN 2) into that port, it's on the right VLAN. (Security issues of this aside).
Lastly, the vlan tag (called an 802.1Q or just a dot-1-Q tag) comes after the MAC addresses. This was done for a reason: So that dumber switches, which forward a frame after the destination MAC address is received, will continue to function--they just become multipliers of your trunk port.