DD-WRT may have the ability to route between VLAN's - however I don't know it so you'd have to check it's manual.
A way to think about VLAN's is to start out by dropping the "V" (virtual) and think about how you'd achieve the network you want using physical infrastructure and simple unmanaged switches.
For example, if you want two LAN's - let's call then "red" and "blue" you'd buy one set of switches and AP's for the red network and connect them all together with red network cables (the colour of the cable makes no actual diffierence, but helps illustrate the metaphor I'm using) and a second set of switches and AP's for the blue network and connect them together with blue cables. Obviously this can be a bit wasteful in terms of hardware as you can be duplicating a lot of hardware and cabliing.
This is where VLAN's start to be useful. Imagine some location where you have a red and blue switch physically co-located. I'll wave my magic "logic wand" and turn the red/blue switches into "virtual" switches and wrap the two switches inside a physical switch - let's make that switch "black." I then need to connect the ports of the virtual red/blue switches to the physical ports of the black switch using sort of "virtual" patch-cords inside the physical switch. In real switches this is done using the UI of the switch which is one of the reasons switches offering VLAN support need a management interface.
So far so good. Imagine I do exactly the same thing with another switch elsewhere, I can then connect the red virtual switch in one physical switch to the red virtual switch in the other physical switch using appropriately configured ports on the physical switches and so likewise for the blue network, thereby extending both the red and blue networks into both switches.
But that's bit wasteful in that I need to have separate cables for each network (imagine if you have many more VLAN's - you'd eventually run out of switch ports for the interlinks.) What we normally do instead is use something called "port trunking." We create a "special" port on each physical switch that is connected to both the red/blue virtual switches, but the "trunk" port is configured to "mark" all traffic that egresses through it with a "tag" that identifies which network the traffic came from. At the other end, the receiving switch (also using a specially configured "trunk" port) "reads" the VLAN tag of any ingressing traffic and directs the traffic to it's red or blue internal switch as required. Thusly, we have maintained traffic separation, but now no longer need separate cables to convey the traffic of each VLAN.
The only real downside of a "trunk" between the two switches is the bandwidth (traffic carrying capacity) of the trunk is shared (usually actually "competed" for) between both networks - but most of the time that's OK especially in lightly loaded SOHO networks (and there's ways to increase the bandwidth too.)
Notice there's no path between the red/blue networks anywhere - they are completely separated. What if we want to allow traffic to pass between the networks...? This is where routers enter the pictures. A "proper" router's job is to move traffic between networks. Often they possess various mechanisms to police what traffic is and isn't allowed between which networks using thing like routing tables and Access Control Lists (ACL.) And each LAN needs it's own way to obtain IP addresses (which incidentally will need to be of different subnets) often by having their own DHCP server, or a "relay agent" that can forward the DHCP requests fro one network to a DHCP server on another.
So our router will need to be connected to both red and blue networks (either physically, or by using trunking) and will need to be taught what traffic flows are and are not allowed - more admin work.
With better quality Wi-Fi AP's, you find similar VLAN separation and port trunking features available. In the scenario I've illustrated above, imagine instead of there being a switch on one end of my "trunk" cable there is instead an AP that "understands" VLAN tagging and port trunks and can be configured so that ingressing tagged traffic is distributed to different SSID's and egressing traffic is "tagged" in the same way as a switch identifying (effectively) which SSID the traffic originated from.
Thusly, with the right kit, correctly configured we can create multiple networks (VLAN's) and multiple SSID which can be kept entirely separate (if we want) or perhaps with some "rules" determining what traffic flows are allowed between which networks as we desire.
We do this sort of thing all the time in commercial environments, we might (for example) keep Finance separate from HR, "corporate" separate from the "shop floor", etc, etc. or I used to work in a university where we kept the (warring) faculties apart, separated "students own" computers from "guests" of our conference centre," etc. etc. Technically it's all much the same process (VLAN's, tagging, different SSID's, etc.) but the politics largely drives who can "see" who.
As you can see, this is not exactly rocket science, but it's not trivial either and you need the "right" kit that can talk to each other the "right" way, (fortunately, it's all "open standards" compliant these days,) and the expertise to set it all up - ie "managed" kit.
If you follow the logic, you'll see that you can in fact use "dumb" unmanaged switches (and AP's) in the mix, provided those switches are only connected to one LAN - they cannot convey both. For example, one could connect let's say a physical port in a managed switch to the "red" VLAN, then connect a dumb unmanaged switch to that port and thus the red network will be presented in the unmanaged switch. But the blue network won't be present in the downstream switch (and if you tried to connect up the blue network also, bad things would happen really quickly!)
Of course, this is all something of an abridged explanation - there's plenty of caveats to explore and "creative" wrinkles that can be exploited. For example, a lot of computer NIC drivers these days are "VLAN aware" (ie they can read/write the VLAN tags) so you could connect up a computer to a "trunked" port and have it connected to multiple networks with a single cable. I've done so with the odd server and often use a laptop this way when I'm fiddling around in the switch racks so that I can "keep an eye" on the all networks whilst I'm playing around and can undo things really fast if bad stuff start to happen. Not that I ever make silly mistakes you understand.
Oh no, not me.