You can create a driver for the visibility of low poly and high poly versions, such that the high poly version of the model is shown when the camera is close, while the low poly version is shown when the camera is not close.
With both a high poly and a low poly made, select the high poly and look on properties/object/visibility. Right click on the checkbox for "Show in renders" and select "Add Driver".
Now open a driver editor view, and edit the driver you just created. Change it to a scripted expression. Set the input variable to be a distance, then specify your high poly object as one object for the distance, and your camera as the other object for the distance. Finally, set the scripted expression. If you use a scripted expression of "var > 10" then the high poly will disappear whenever the camera is more than 10 units away. (Yes, this seems backwards; Blender's drivers don't always match the text, and in this case evaluating as True means that the object isn't shown in renders.)
Because you're concerned about performance, you'll want to duplicate this driver to "Show in viewports" property as well.

For the low poly, you'll want inverted drivers, so you'll want to set the expression to var <= 10 (in this example.)
Whenever you duplicate one of these objects, the driver will update the distance to measure the distance for the new object, at least in 2.92.
There are a few concerns regarding this plan however. The first is pop. If you zoom in on a low poly tree, it will suddenly be replaced all at once with a high poly tree. This is a common problem in level-of-detail systems, and you've probably seen it in action in video games.
Another issue is that distance isn't always a good measure of how much screen space something is taking up. Trees behind the camera may not be visible at all (or may be, via Cycles ray bounces.) When you look at trees through a refraction mesh that simulates a telescope, they may be distant, but take up lots of screen space. If you decrease the field of view, things take more screen space, even though the distance hasn't changed. With more math, it's possible to work around FoV, but with something like refraction, you just don't know until you raytrace it, at which point it's too late to do anything.
Also, there's not all that much performance to be gained. Even though they're not displayed, all of those high poly trees need to remain in memory for Blender. The main performance increase you're going to see here is going to be for rendering-- which, yes, includes viewport rendering. But if you're having laggy solid view rendering, it's hard to imagine that making LoD drivers for everything is going to provide any noticeable improvement.