Acceleration Values Where?

When you say "upgraded to bearings" Does that include the Y-Axis drive shaft with a pillow block?

Bearings will make relatively little to no difference to your acceptable acceleration vectors, as the limiting factor is both the already over-driven X-axis motor and right-on-the-limit Y-motor. The other rarely mentioned issue is *deceleration* which is derived from the same numbers. The constraints around decel are about weight (of the print head for the X axis and of the entire X-Axis assembly for the Y-Motor), and arguably, with bearings, is made worse as overshoot is easier....

Check out http://calculator.josefprusa.cz/ and the last calculator to get a feel for how different vectors effect how you accelerate and decelerate over various distances...

Anyway - if you feel theres something to be found:
Slic3r Advanced acceleration values sets the GCode generated acceleration vectors when in the various print modes.
RH's EEPROM Acceleration values impact the Firmwares max values - the firmware will not process movements using values above those vectors and will keep them constrained to those values (i.e, it is the 'cap'...).

In short - You could put what you want in Slic3r, but it will always be trimmed/capped by EEPROM...
Except for the few places where that all goes out the window inside Marlin... but these tend to be limited to edge cases.

One suggestion as well is to spend some time with QT-Marlin if you want to play with acceleration vectors.. it will require you to rig a full set of end-stops though, as it detects the acceleration success/fail by measuring missed steps across a known distance between two end-stops in both directions.. but it at least takes the heavy lifting work out of trying to arrive at reasonable figures.

A couple of things here.
1. Don't under estimate the value of the pillow block.  Pull that rod out and spin it with a drill use some emery cloth to turn it down till your bearings fit.  This only needs to be done on the first couple of inches.  I have six bearings on mine (overkill I know).  two replacing the bushings in the case and two pillow blocks (two bearings each) on each side.  I absolutely couldn't believe the huge difference it made.  Especially the one on the left side.
2. I have bearings on my front idlers and used a set screw to secure it to the bolt (don't tighten the bolts too much).  Now those bolts spin with the idler pulley.  If I remove the Y-Drive belt to the motor the movement is so smooth that a strong breeze will move it back and forth.

I agree more is better as long as they are aligned too. I realize my Z rod has a hitch in it at about layer 24-30. every print it gradually shifts left then back again so all my prints in the X have a mild bump to the left. I redid my Z with a slop spacer mod and with the bearings it helped a lot to minimize it but it is still there. So I will do a 5mm rod upgrade, probably replace the Y servo with a hi torque setup and while in there I will try one more time to install the pulley on the back and the idlers on the front.

So far it is much more improved and my litmus test is the sound. I know all is great when I hear a nice mild humming of the servos with the extruder fan running. If i hear some clunking of the extruder head or popping of the carriage I know I am getting some slip or bind. I still have that in some areas but I suspect it is the loose linear bearings now slipping. next project will be to reprint the y slides and drill hols so I can twist tie the bearings in place.

I am not sure why but that video made me smile the whole way through.

Its a QT program.. so you have to 'compile' it (on Linux, or Windows..) ... and it runs standalone and connects to the printer directly.  But hey, no love lost if thats a bit complicated - was just a suggestion for having a repeatable and automated method for determining the maximum acceleration you can achieve... by no means neccesary (you would note in that image that the program does exactly what you are after - but in that case he was testing for highest speed with 10000 as the acceleration vector, so he was testing it in terms of keeping highest accel with best speed rather than reducing accel to get higher speeds... But basically it keeps upping the acceleartion/speed value by a set value and keeps running the test until it fails... and then you know your highest acceleration/speed is the value used before the failed test ..) .. It just makes it easier for us lazy people

You can do it all by hand yourself in G-Code.. just write a big text file and paste it in to RH... Use the G-Code EEPROM adjustment commands to adjust the acceleration between each iteration, and you can then use a set of define movements (say full strokes in both directions, then half strokes, then a diagonal) to test the performance. Then you can just cut-n-paste that set of g-code numerous times and just adjust the G-Code line for the acceleration vectors.