Okay, because of the various different responses you keep getting, I'm not really sure how to interpret your request.
Perhaps a diagram would help?
Some clarifying questions...
Are you saying that each tenant in the MTU will be associating to your network wirelessly, or merely that the MTU building will be connecting to the internet with a single wireless connection and then you are breaking out ports on a VLAN'd switch to each unit in the place?
If the former, I don't think there's any way to do what you want, nor do I really understand why it would be desireable. If you have an AP, and you want each client's traffic to be separated into its own VLAN, well, in 802.11, each SSID only works as if it is a "single" switchport. You can't "untag" multiple VLANs on a single switchport and expect things to work.
So you would need to deliver traffic to every associated client with the 802.1q tags intact, their wireless client would need to be able to decipher 802.1q-tagged wireless frames, and each tenant would need to manually program their wireless client so that it knows what VLAN-ID their traffic has been assigned.
And this is all assuming that 802.1q and 802.11 get along...I'm not sure that 802.1q works reliably (if at all) over 802.11 frames. It would be WAAAAY easier to just set up a PPPoE client on every tenant's computer and turn "default-forwarding" off on your AP interface to get the kind of traffic separation/security that it sounds like you desire.
The other (equally convoluted but technically possible) way that you could achieve VLAN-to-WLAN-association mapping would be to use an Atheros card as an AP so that you could take advantage of the Virtual-AP interfaces. Create a separate Virtual-AP per VLAN/customer, give each VAP a distinct SSID, and then bridge the VAP with the VLAN interface you wish to assign to it. Presumably, in order to make sure that there was only one customer per VLAN and that the customers were on the VLAN you intend for them to be on, you'd have to use some kind of security/enforcement, such as turning off "default-authentication" and adding their wireless MAC statically to the wireless access-list for their VAP interface, or perhaps giving every VAP a separate WEP/WPA key that only the customer who is supposed to associate to it is privy to.
This sounds like a whole lot of trouble for little questionable benefit. If everyone had their own PPPoE tunnel on a single AP interface, even without default-forwarding turned off, I can't imagine that customers would (typically) be able to peer into the other PPPoE tunnels that their neighbors are using. PPPoE tunnels in this case effectively == VLANs.
Now, if what you mean is that you have a wireless connection to the building and a switch + MikroTik in the building that you are using to separate each tenant's traffic (presumably connected via good-ol' hard-wired ethernet) into different VLANs, and rather than routing all of those different networks to a single outbound you wish to map each VLAN to a specific pppoe-client interface, then it should be possible to do what you want, I would think. There will be some tricks to doing so, though, and I don't think you will be able to automate most of this through RADIUS...most of the configuration will have to be done statically on the PPPoE-client "concentrator" MikroTik, as you have been referring to it.
If the DHCP pools for the different VLANs are handing out IPs from the non-publicly-routable space, for example, I think you could do something like...
/ip address add address=192.168.x.1/24 interface=vlan-x
/ip firewall nat add chain=srcnat src-address=192.168.x.0/24 out-interface=pppoe-client-x action=masquerade
...for every VLAN + PPPoE-client pair 'x'. In addition, you will need to set up some kind of policy for routing as sten pointed out earlier:
/ip firewall mangle add chain=prerouting src-address=192.168.x.0/24 action=mark-routing new-routing-mark=customer-x
/ip route add gateway=[PPPoE-remote-IP-x] routing-mark=customer-x
...where 'x' follows the same convention as before (VLAN or customer #x), and [PPPoE-remote-IP-x] is the remote-address value that the PPPoE server/concentrator assigned to itself for tunnel 'x'.
Now, here is where it gets tricky. Most people set up their PPPoE servers/concentrators (not talking about your "client concentrator" here, and the fact that I have to clarify this is why I dislike the use of the word 'concentrator' for anything other than the PPPoE server itself!) so that each tunnel that comes up has the same "local-address" (from the concentrator's perspective, or "remote-address" from the client's perspective). When the PPPoE tunnel comes up on the client-side and "add-default-route" is set to "yes" for that PPPoE-client interface, the gateway for that 0/0 route will be the IP address that the PPPoE server is reporting it has to the client. If all of your clients on the MikroTik at the MTU are concentrating on the same server (and, if they are all coming back to you on the same wireless link, they most likely are) and 'local-address' on that server's PPP Profile is the same for every tunnel, then the MikroTik PPPoE client "concentrator"/router at the MTU will not know which PPPoE client interface to send traffic out to, because every PPPoE tunnel running on it will have the same remote-address value!! This is a problem, because when you are statically adding routes, you cannot specify "interface=x"...the interface is automatically determined by the MikroTik when it looks to see which interface the gateway that you specify is connected to.
There is a way around this, however. You simply need to make sure that for every PPPoE tunnel that comes up on the server, it assigns itself discrete 'local-address' values per tunnel, and then make sure to use that value for the gateway fields on the client end when adding your routes. You can do this by setting the 'local-address' value statically for a given user under '/ppp secrets', or you can assign an entire IP Pool to the 'local-address' value for the profile you are using for the PPP Server under '/ppp profile' (but that might not work out since, when you assign the IPs dynamically from a pool, you aren't guaranteed to get the same remote-address for the server from the client's perspective, so the route on the client will break if the tunnel goes down and comes back up...it might be possible to script something up on the client that can programmatically determine what the server told the client its remote-address was for a given PPPoE-client interface). I think it might even be possible to tell the PPPoE server what to use for a local-address via RADIUS, which would probably be what you'd want to do anyway.
Also be sure to turn 'add-default-gateway' OFF for every PPPoE-client interface you create on your client "concentrator," with the exception possibly of the PPPoE-client that you will use for management of the MikroTik (if you use a PPPoE client to access the MikroTik from afar, otherwise just create a static default route yourself for the purpose).
You may need to tweak some things and play around with it a bit, but hopefully that will get you started. Mapping VLANs to distinct PPPoE client interfaces through routing is an interesting idea, but in the end it may be more practical to do something like stretch some tagged VLANs through the wireless link (if you're using something like nStreme+WDS), bridging those VLANs with the customer VLANs (one bridge per customer), and then do all your routing on the MikroTik at the other end of the wireless link. I dunno. I guess it depends on what exactly you are trying to do and what your purpose/goal in all of this is.