Naked eye stars are not distributed uniformly in the sky. That is because the median naked eye star is at a distance of 440 light years, and this is far enough away that some of the details of Galactic structure start to become apparent. Most importantly, the density of stars increase towards the Galactic midplane and has a scale height of a few hundred light years and thus there is an overdensity of stars towards the Galactic plane.

I did an analysis of this in https://astronomy.stackexchange.com/a/10260/2531 , but the important plot is repeated below. It shows the normalised density of stars (per square degree) as a function of Galactic latitude. You can see the peak at low Galactic latitude and even work out that our viewing point is probably slightly above the Galactic plane, given that the peak is at about $-10^{\circ}$. The peak is still there in 3rd magnitude stars. You could repeat for a sample limited to very bright stars, but you run into number statistics trouble.

The distribution of bright stars with Galactic latitude.

EDIT: Extra mile time. Below I show the Hipparcos data, divided into 4 apparent magnitude bins. Points are plotted on a RA vs Dec Aitoff projection. Superimposed in red is a Galactic coordinate grid. There are too few stars with $V<2$ to form much of an opinion, but for fainter stars, a ring-like structure, coincident with the Galactic coordinates equator (i.e. Galactic latitude of zero, or just below, as I showed in the 1D projection above) is clearly seen.

Alright I finally finished this program so I could take a look at each tier individually and see for myself.

First of all, the projection type does indeed matter, so I will explain it here. It needs to be an equal-area projection. The whole point of the question was about a uniform distribution of stars over the surface of a sphere. In other words, each area of the sphere would tend to have the same amount of stars as each other area. Therefore, a projection that preserves equal areas is necessary.

Every map projection type causes some kinds of distortion. It is inevitable. It's in the nature of geometry when taking a sphere and flattening it to a rectangle, or other flat shape. You can see this in the equi-rectangular map of Earth, where Greenland appears the same size as South America.

But that's of course wrong, an artifact of distortion. Take a look at the globe, or an area-preserving projection such as this cylindrical equal-area one, and you'll see that Greenland is actually much smaller than South America.

I illustrated this because, when it comes to points of light, distortions are not so obvious. You don't have the luxury of familiar terrain shapes like Greenland or continents, to tell distortion. So now I'll show a randomly generated starfield, in two projections.

This is a random starfield in Cylindrical Equal-Area Projection.

This is the same starfield in Equi-Rectangular Projection.

Both of them look pretty uniform, but the last one has a lack of stars near the poles. Without understanding what projection is used, and their pitfalls, you could think that the second one is not uniform.

From here on out I will use the Cylindrical Equal-Area Projection unless otherwise noted. These put the 0 RA 0 DEC point in the center, so the poles are at the top and bottom.

Now I'll show the actual starfield of our sky, based on the Yale Bright Star Catalog. Thanks to user:RobJeffries for pointing it out. I took stars from Sirius to 4.99 apparent magnitude. This was 1,602 stars.

It's a little difficult to discern, but there is a path where stars tend to cluster around the Milky Way. It's hard to see on the left side of the map. On the right side it's easier.

By the way, I did not draw brighter/dimmer stars differently, such as a smaller or grayer point of light. I wanted each point to show up just as well as each other point, because for one thing, I planned to look at each tier individually and in progressing composites.

Here are the fields only looking at one tier at a time. There are 5. The first includes stars from Sirius to 0.99 apparent magnitude. The second goes from 1.0 to 1.99, etc, ending with 4.0 to 4.99.

In my opinion, the only one that could possibly be close to uniform distribution is tier 4, the stars with apparent mags from 3.0 to 3.99.

So now here are the composites. There are 3 of them. The first has tiers 1 and 2 composited together, The second has tiers 1 to 3, and the last has tiers 1 to 4. (All tiers, 1 to 5, was done in the original screen shot of our starfield.)

I suppose the closest one to uniform is the last one, but it's not as close as tier 4 by itself. I'm not really sure why that is or if it's just a coincidence.

Finally, what I want to do is an actual numerical/statistical analysis on the coordinates, at least for tier 4. Sadly I cannot remember how to do that. It's been too long since my stochastic models class in undergrad, and I'm not even sure if we ever learned how to do that. I will search around and try. If I get it done, I will come back here and edit this answer.

I am satisfied, of course, that the stars in the sky are not uniformly distributed. I wanted to post this answer because I did the actual work and wanted to explain some things. It took maybe 5 hours of work, spread over 2 days. 2 hours were a total waste tho, copying the 1.0 to 1.99 stars from Wikipedias list. Another hour just searching for star catalog in a format or interface that I could understand. And now that I look at the time, it's taken almost an hour just to type up this answer, which seems impossible.

Now I will show source code for a few things. First, the code to generate a uniformly random starfield, because it's not as simple as you wold think.

repeat (1000)
{
  hdeg = 360 * random(1);
  //vdeg = 180 * random(1) - 90;
  vdeg = arccos(2*random(1) - 1)*180/pi - 90;

  scr_ini_star2(hdeg, vdeg, 0, "");
}

I left that middle line commented out, to show that it's wrong. The "obvious" solution is just a longitude from 0 to 360, and a latitude from -90 to 90. But that does not form a uniform distribution. Wolfram Alpha has more information and I'm not sure I understand it fully myself. For some reason you have to use that arccos.

Next is the code to translate the spherical coords to xy coords, or in other words, map a projection. Notice that I made maps in an 800 x 400 pxl format. I chose this to make it easier to switch between equi-rectangular and cylindrical equal-area.

// cylindrical equal-area

x = (400 + RA/360*800) mod 800;
y = 200 - sin(degtorad(DEC))*200;



// equirectangular projection

x = (400 + RA*800/360) mod 800;
y = 200 - DEC*200/90;

The RA/DEC translation code, from hms or dms to degrees:

  RA = (argument0*3600 + argument1*60 + argument2)*360/86400;
  DEC = argument3 + argument4/60;

I wanted to post the entire body of star list initialize code, but discovered a character limit of 30,000 on stack exchange. It was only 1,602 stars... Learn something new every day, but here is a small sample.

scr_ini_star(18, 36, 56, +38, +47, 0.04, "");
scr_ini_star(05, 16, 41, +46, +00, 0.06, "");
scr_ini_star(05, 14, 32, -08, -12, 0.15, "");
scr_ini_star(14, 39, 36, -60, -50, 0.33, "");
scr_ini_star(07, 39, 18, +05, +14, 0.36, "");
scr_ini_star(01, 37, 42, -57, -15, 0.49, "");
scr_ini_star(14, 03, 50, -60, -22, 0.61, "");
scr_ini_star(19, 50, 47, +08, +52, 0.75, "");
scr_ini_star(12, 26, 36, -63, -06, 0.80, "");
scr_ini_star(05, 55, 10, +07, +24, 0.80, "");
scr_ini_star(04, 35, 55, +16, +30, 0.86, "");
scr_ini_star(13, 25, 11, -11, -09, 0.97, "");

The first 3 fields are the hours, minutes, and seconds of the Right Ascension (RA). The next 2 fields are the degrees and minutes for the Declination (DEC). Warning, the minutes are NOT the same thing there. The minutes in DEC are minutes of arc, where 60 minutes is in 1 degree. The minutes in RA are actual minutes of an hour. 1 hour is 15 degrees, and 60 minutes in an hour.

Another warning. With negative declinations, you have to put the minus sign on the minutes too...and seconds if they're there. The database file I found did not have seconds in DEC, but I don't think that level of accuracy was needed for an 800x400 map.

I made this little project in Game Maker 8.1, an old IDE from the late 2000s and early 2010s, but still the fastest way to do small graphical calcs for me. It treats every variable as a double, so I never had to cast anything as a float or double before doing division.