I don't think you can quite get there trying to enforce binary order multiples like that, even with creative use of min max and multiple order quantities. If you set min at 1250 and max at 2000 without a multiple, you'll get as you've noted any number in between. To resolve this, you'd need to set a multiple, but multiple of 1250 would prohibit an order of 2000, and multiple of 2000 would prohibit an order of 1250. Multiple of 1000, I think, would prohibit the 1250 minimum enforcement and round it up to 2000.
You can use BOM/route versions to establish the materials and resources needed for each of these batch sizes, but that won't help generating the appropriate planned order quantity, just dictates which BOM/route is used after that order is generated.
The only way I can think of to work around this would be to create two separate products, one for 1250 batch and the other for 2000, then you could try monkeying with higher level BOM's and setting up large and small quantity versions pointing to the respective lower level product.batchsize products, but this wouldn't fit well where you want the consolidated requirements grouped into planned batch orders.
You're basically trying to enforce a multiple-order-multiple strategy, which is definitely not something standard MRP methods support. It's probably not a complex customization, though--you'd set up a special coverage group name, then code an algorithm to figure out how to most efficiently break up consolidated demand into orders of 1250 and/or 2000, then feed that back into AX as planned batch orders in the background. The logic would say something like if REQ<=1250, Oqty=1250, else if REQ<=2000, Oqty=2000, then if REQ>2000 you'd need to incorporate some multiple/remnant logic to optimize the minimum total order quantity using combinations of 1250 and 2000 towards total REQ. Might be as simple as limiting to a single 1250 with the rest 2000 or a single 2000 with the rest 1250, but I'm not monkeying with the math to figure this one out this morning :-)