Let's cover the simple part first - Meraki switches do not support Secure Group Tags. Meraki switches are unable to provide host to host segmentation in the same VLAN using SGTs.
However, TrustSec has a process to enable a TrustSec fabric to extend to a non-SGT enabled edge. This capability leverages ISE to make IP-SGT mappings and pass them to SGT enforcement points in the network. Meraki has the ability to send the necessary information to ISE, allowing a Meraki L2 edge to support a TrustSec enabled network from datacenter, WAN, and core.
If I'm reading the diagram correctly basically it consists of using a Nexus 7k at the network border. I'm guessing we're using something similar to OTV similar to how you use it for DCI? However it works that's going to give us the the information for the IP tags that will be fed to the Access Switch Say a MS 350. Then we use 802.1x?
Consider if the Meraki MS switch is at the access layer, and the Nexus 7k is the core. Ignore the ASR for this scenario. We aren't using OTV or anything crazy like that. A user authenticates on the MS switch with 802.1(x), and the MS passes the client's IP address over RADIUS to ISE. ISE then sends the IP to SGT mapping to the Nexus over SXP.
The MS350 is unaware of the SGT enforcement at the core. It authenticates a user via 802.1(x) and places that user in a VLAN. The L3 boundary is at the Nexus, and that is where the SGT / TrustSec magic happens. This actually isn't technically in the whitepaper, but I hope you can see that the SVI for the VLANs on the MS could easily reside on the Nexus for a campus deployment.
The ASR allows this document to also show a case where the Meraki switch is multiple hops from the datacenter core, for instance over a WAN. In that case, the same scenario happens, with SGT encapsulation and enforcement at the datacenter. The traffic runs across the network represented by the ASR un-SGT-encapsulated, until the Nexus applies SGT and enforces policy.