You need vsx_provisioning_tool for VTIs on VSX:
vsx_provisioning_tool -L -o add interface vd VS1 vpn_tunnel numbered peer SmartConsole_interoperable_peer local 169.254.68.238 remote 169.254.68.237 tunnel_id 99
Replace VS1 with the name of your firewall Virtual System.
Replace "SmartConsole_interoperable_peer" with the name of the Interoperable Device in SmartConsole for this VPN peer.
This will create vpnt99 for your VS. After this, you should be using Route Based VPN with empty group objects as the VPN domain for the remote peer and your VS. You can override VPN domain for the peers within the VPN Community, rather than modifying the main VPN domain on the VS object.
You will also need to add static routes across the VTI for whatever remote end host they gave you. You add static routes in SmartConsole for the firewall VS. These are in the VS properties -> select Network Management on the left, and you'll see the where to add static routes. Use the remote peer IP in the VTI as the next-hop gateway for the route (169.254.68.237 in this case).
You can replace those 169.254.x.y IPs in the VTI command above, but be sure you ONLY use IPs in the 169.254.x.y range! Don't try to use any 10.x or 192.168.x.x addresses; these are unnecessary. A VTI is a virtual point-to-point interface; the IPs really don't matter, and they don't even have to be remotely similar. For a point-to-point interface, no matter what packet you "write" to that pseudo-wire, it will be sent. So use the APIPA address space; that's what it's for, link-local addressing.
FYI: If you have Multi-Domain management, then you first need to switch to the Target domain where the VS is created before running the above command:
mdsenv TARGET_DOMAIN