and who/what is advertising IPv6 in your network?

Anyway, DNS advertising is not on by default in RouterOS. You have to head over to /ipv6 nd to set it to be included in the RA. Also, ipv6 DHCP is not capable to do that if ipv6 package is disabled as there are nothing ipv6 related underneath that would allow DHCP server to bind and send out MLD packets.

Some servers like google and probably facebook have implemented ipv6 so you will see an ipv6 address if your PC has got ipv6 enabled. This has nothing to do with mikrotik and is something your PC already supports and uses where possible.

at times windows uses the last known working configuration on the network so even without a DHCP server it will still use the same settings on the same network. At one point you had ipv6 on mikrotik so the client shows that whenever it connects. The DHCP server only gives out details, it doesnt control what happens after. Clear your client cache and settings.

open winbox and search for your routerboard. If you dont see an ipv6 address from it that means that ipv6 isnt running on it and your client settings need to be cleared. If you do see it than it is a routerOS bug.

@ddejager: What about the second question? If you run ipconfig /all, do you see any IPv6 addresses?

You have two different problems here:

1) IPv6 DNS servers addresses

This alone should not matter at all. If system does not have any IPv6 address, it won't use those servers. It can try, but as there is no route to them, it will fail immediately and move to using some reachable IPv4 DNS server.
I tried it, I manually added two IPv6 DNS servers to system without IPv6 addresses and even though nslookup tries to use one of them, the failure is instant.

2) Clients trying to connect to IPv6 addresses

Unless your client is haunted or something , it simply can't happen. If system does not have any IPv6 address, no correctly written program will get IPv6 address from hostname, unless it specifically asks for IPv6. But even if it did, the result would be exactly the same as in 1). No IPv6 route => instant failure => no slowdown.

Yep, it helps a little. There is indeed default route and I verified here that it's set by Teredo.

It still does not explain, where those IPv6 DNS servers come from. I'm not completely sure, but I think that Teredo can't set them. Even if it could, it would be strange, because the address of your Teredo server (5ef5:79fd => 94.245.121.253) belongs to Microsoft, while DNS addresses belong (as you already know) to Comcast.

You could disable Teredo, but it's not a solution, just a workaround. But I just found this nice command and it should show something interesting:

netsh interface ipv6 show dnsserver

Microsoft Windows [versão 6.3.9600]
(c) 2013 Microsoft Corporation. Todos os direitos reservados.

C:\Users\Guilherme>nslookup google.com
Servidor:  UnKnown
Address:  192.168.234.17

Não é resposta autoritativa:
Nome:    google.com
Addresses:  2800:3f0:4001:811::100e
          173.194.119.32
          173.194.119.34
          173.194.119.41
          173.194.119.46
          173.194.119.40
          173.194.119.37
          173.194.119.39
          173.194.119.38
          173.194.119.33
          173.194.119.35
          173.194.119.36

Hostnames are mapped to IPv6 addresses by AAAA records in the DNS. Not all nameservers properly support queries for AAAA records.

There are two categories of bugs:

1) Nameservers which silently ignore AAAA queries. BIND 4 is notorious for this bug. This bug causes clients to wait for their AAAA query to timeout and frequently leads to the perception that "IPv6 is slow."

2) Nameservers which improperly respond to AAAA queries. It is common for a host to have an A record, but not AAAA records. When a namserver received a AAAA query, it should respond with NODATA, indicating that it does not have an AAAA record, but does have records of other type. Some nameservers are broken and return NXDOMAIN, which indicates that the server does not have records of any type for the hostname. This causes clients not to query for A records. Microsoft has a KB article about this issue. See RFC 2308 for more on NXDOMAIN -vs- NODATA.