Please share the architectural rationale behind your hypothesis that LoadRunner cannot be used to conduct these types of tests.
For your two questions
1. LoadRunner supports two types of VDI clients, Remote Desktop and Citrix. As you have noted terminal services (remote desktop), then it would seem that your testing can be supported. As you are trying to answer terminal server performance, just pick a bog, thick, ugly resource app to navigate using RDP. I use Microsoft Office components for this type of test
2. LoadRunner has a long and rich history of thick client support, ranging from a low level interface like sockets, to a high level interface such as actually operating the GUI with graphical virtual users, with support for direct to database (ODBC, SQL Server, ORACLE, DB2, ...), middleware (Tuxedo, Java, .Net, ...), services (SOAP, REST, ...) and custom using Visual Studio to leverage source code or dynamic link libraries.
This is where you leverage your architectural foundation skills. Examine carefully the installation and configuration guide for your "Team mate" software. Look specifically at the client installation model and requirements. What pieces of software are called for? What do you need to configure for connection from the client to its next upstream architectural component? What apparent API or interface is being expressed by the installation manuals? When I record a wireshark session what well known ports or communications protocols are identified? When I record using Winsock and examine the first five buffers for the client to next upstream component handshake what servers/versions/protocols to I see identified in clear text?
Then you move into your tool foundation skills. How can I map these items to what is available in LoadRunner? Once I have a working hypothesis, what can I do in LoadRunner to test this hypothesis on the nature of the interface and whether I can record 'X,' need to select another protocol/interface or take a different path?