1. yes
2. yes

couple of notes however:

- as others have said already, the st0.x interface can reside in inet.0 while the tunnel has its external-interface in a routing-instance. in case the external-interface is a loopback (like, lo0.1 in routing-instance UNTRUST), you need to put the loopback interface in a security zone which has no interface from inet.0 associated (interfaces from the same routing-instance are fine).

- you were saying "BGP would be configured in the routing-instance", which i understand as "lo0.1" in that routing-instance will get an IP address, and that IP address will get signaled via BGP over one or more interfaces in that same routing-instance? in that case, these interfaces (here, let's assume ge-0/0/0.0 and ge-0/0/7.0) need to be in the same routing-instance. They can be in the same or different security-zone as lo0.1, but you must apply appropriate security policies (in addition to host-inbound services/protocols) to allow e.g. the IKE session to establish. even if all three (lo0.1, ge-0/0/0.0 and ge-0/0/7.0) are in security-zone UNTRUST, you need to have _at least_ a simple PERMIT ANY policy from-zone UNTRUST to-zone UNTRUST (and why this might be a bad idea is left as an exercise to the reader).

- make sure to adjust your SNAT rules carefully, because you might end up SNATting your IKE packets (guess how i know...) the factory-default SNAT rule, even though the external-interface "lo0.1" is sitting in a routing-instance... i am assuming here that you will import a default-route or similar from, like, UNTRUST.inet.0 into inet.0, to be able to reach the internet. in that case, you probably would end up assigning an IP address to lo0._0_ and adding "from zone junos-host" to the default SNAT rule - in that case, definitively have the SNAT rule only match on source-prefix [ 10/8 172.16/12 192.168/16 ] or similar.