The best practice would be to deploy consul clients to each node. Depending on your use case, this might not be worth the effort since you say that this is temporary.
The primary reasons for running clients on each node are health checking and performance.
Consul clients gossip with one another to determine if they’re healthy. If one of your nodes dies, Consul will quickly discover this through gossip and any services on that node will be marked as unhealthy. If using Consul DNS, this means that the services won’t be returned in the DNS call and so you won’t route to unhealthy services. If using the go api, there would be no way to mark the services as unhealthy unless you had something out-of-band doing this. You can also create health checks for your services that are performed by the Consul client. If there is no client then there’s nothing to run the health check.
For performance, the Consul clients pipeline all requests through a single connection to the Consul servers. In your case, it sounds like you’d only have a couple of instances of the go-consul api running, so you’d actually likely have less connections.
So overall, it might make sense in your use-case but it’s not a best practice. There might be other issues that will arise since it doesn’t follow Consul’s model. That being said, in Kubernetes we actually use the API to register Kubernetes services onto a “fake” node so that’s an example of using the same method you’re contemplating. See https://www.consul.io/docs/platform/k8s/service-sync.html