At this time there’s no built-in support for end-user accessible tokens that could be used to provide access to a third-party application in a similar process to the GitHub personal access tokens you mentioned. This possibility is something on our radar and listed in the backlog, however, it’s not yet available.
At this point if a third-party application wants access to your API on behalf of an end-user then it should perform the typical OAuth2 dance where the user would authorize the application and then the application could obtain access tokens suitable for the API. This implies that the client application needs to be able to talk OAuth2 instead of just including a single-piece of data provided by the user in each request (the so called personal access token). In addition, the client application would need to be registered in Auth0 which could either be done manually or leveraging dynamic client registration.
In conclusion, if I understood your scenario correctly the so called personal tokens that could be generated by a user and just provided to any application as a quick method to allow the application to call the API on behalf of the end-user is something that is not yet available, however, access from third-party application is already supported as long as they follow the OAuth2 protocol; you mentioned non-interactive, but I’m assuming something like a command line application instead of something without any sort of interaction with the user as otherwise it would also be complex for the user to provide the personal access token so in this case the CLI could perform a one-time authorization setup much in the same way as a native application would do and in the process obtain a refresh token that would mean continued access without requiring further interaction from the user.