Although it is the best practice to locate each IP subnet to a dedicated VLAN, VLAN and IP subnet are not the same thing. So ignore VLANs for a while and concentrate on the subnets alone. In order that devices in subnet a.a.a.a on router A could talk to devices in subnet b.b.b.b on router B, a route to subnet b.b.b.b via the GRE tunnel must exist at router A, and route to subnet a.a.a.a via the GRE tunnel must exist at router B. Plus the firewall must not block the traffic of course.

And yes, GRE tunnel doesn't carry L2 frames, only L3 packets, so no way to tunnel VLANs as such via GRE. But you don't need that either, as said above.

ping times out from router A to B (but not vice versa)..
...
I can't see any firewall activities either, so don't believe firewall is blocking it.

Sorry, the first thing I've spotted in your OP was that whilst there were four subnets, 192.168.11.0/24 to 192.168.14.0/24, at router B, there was only a route to 192.168.12.0/24 on Router A, whilst you wrote that "Router A, however, cannot ping any devices on the various VLANs". So I wasn't careful enough when reading the other details, assuming that you were testing on addresses for which no routes existed.

Now as you've stated again that the pinging works in one direction but doesn't in the opposite one, and have shown the particular IPs you are pinging between to match the existing routes, as well as the fact that you've explicitly indicated to the originator the source address to use, it means that the route to 192.168.62.0/24 at router B and the route to 192.168.12.0 at Router A are both correct, otherwise the responses in the successful ping case would not come back to the originator of the ping.

So the issue must be caused by a firewall, but not necessarily (or rather not only) on the Mikrotik routers themselves.

When pinging from an own address of the router, firewall chain output on that router handles the outgoing requests and firewall chain input handles the incoming responses; when you ping to an own address of a router, input on that router handles the incoming request and output handles the outgoing responses. When you ping to or from from some other device connected to a router, that router's firewall chain forward handles both the requests and responses, and the firewall on the device itself may also block the traffic (typically, Windows firewall by default only responds to ping requests from the own subnet of the interface to which they arrive).

All the above is valid for the ping requests and responses, i.e. the payload of the tunnel.

The transport packets of the tunnel that carry the payload, i.e. the GRE ones, are always handled by chains input and output (because they are always sent and received by the routers themselves), but also by chain forward (or in some equivalent way) of all the routers on the path between your two Mikrotiks (if they bother about filtering traffic at all). So if there are short pinhole lifetimes somewhere, the transport packets may not reach the destination in one direction, unless the pinhole has been previously open by a corresponding packet in the opposite direction.

Also a src-nat rule on Router B, or a dst-nat one on Router A, rule may cause a trouble in pinging from .12.1 to .62.1 if not selective enough - these rules always handle only the first packet of a new connection, and the resuls is then applied on all the subsequent packets of that connection. So such a rule only affects one direction of ping.

Sniffing is of great help here - you can see, while pinging, how far the request and, eventually, the response did get on each router, and whether there was some NAT manipulation on either.

/tool sniffer quick ip-address=192.168.12.1 ip-protocol=icmp at Router A, and /tool sniffer quick ip-address=192.168.62.1 ip-protocol=icmp at Router B will show you what happens with the icmp packets; /tool sniffer quick ip-address=ip.of.router.B ip-protocol=gre at Router A, and /tool sniffer quick ip-address=ip.of.router.A ip-protocol=gre at Router B will show you what happens with the transport packets.

That did the trick! Just adding an address to the GRE tunnel on each side solved it!

That sounds like some NAT issue. Do the sniffing as suggested above and see where the IP address assigned to the GRE interface is used instead of the one specified in the src-address parameter of the ping command.

Since GRE is a point-to-point tunnel, the name of the interface is normally sufficient as a route's gateway.

I would be careful with "defaulting to use ether1's address". For packets sent by the router itself, the route to the destination is found first, and only then the source address is chosen, using the properties of that route. If no pref-src parameter of the route is specified, RouterOS chooses the address associated to the interface which is set as the gateway of the route or, if gateway is an IP address, the address of the interface via which the gateway IP is accessible. A src-address eventually specified manually overrides both if it is an own address of the router, attached to any interface. And a src-nat (or masquerade, which is a src-nat with additional features) rule overrides all three. Why this hierarchy has failed in your case is not clear to me, nor it is clear to me why the public IP in particular has been chosen to overridde the one specified as src-address.

Can you add a rule chain=srcnat action=accept dst-address=192.168.12.1 as the first one in its chain in /ip firewall nat (to shadow any subsequent ones for packets towards 192.168.12.1) and see what the source address of the ping packets will be when no IP address will be assigned to the GRE interface?

Interesting... what if you set the pref-src of the route via the GRE interface to 192.168.62.1, of course still with no IP address attached o the GRE interface? What are the RouterOS releases on both machines, given that they behave differently under apparently same conditions?

I guess it's a behavior of x86 implementation.. maybe?

Possibly... I was actually asking about the release (like e.g. 6.47.10), not so much about CPU architecture, but yes, it's true that a few things behave different depending on the CPU architecture, I just didn't expect something this essential to behave different.

Knowing that it is a CHR allows me to test on one of mine.