TL;DR: not the OpenStudio Results measure, no

A Reporting Measure, such as OpenStudio Results, does things at two different points in time. If you consider the following logic to go from an OpenStudio Model (.osm) to your .html file.

OSM ------ Forward Translation ---[1]---> IDF ----- Simulation -------> Results (.sql) ---[2]--- Reporting---> Reports (.html)

At [1]: it runs code on your forward translated IDF file (after E+ pre-processor really, omitted for clarity), the idea is mostly to create Output:Variable and Output:Meters, etc: anything needed for the appropriate results needed by your Reporting Measure to be available in your SQL file post-simulation.

At [2]: it first runs code to associate the model (OSM) to the results database (SQL), then it basically computes some values etc from a mix and match between what's available in the model directly versus direct SQL queries. Ultimately the ruby variables that store these values is passed on to an ERB (Embedded Ruby) template: you fill the placeholders in that "special HTML" (ERB) file to produce the HTML.

All that to say that in general, you should very well be able to run a Reporting Measure on an .idf, at least via a similar method that is used in measure testing where you would explicitly call the two separate methods (energyplusOutputRequest [1] and run [2]).

In the case of the OpenStudio Results measure though: a lot of the code used to produce summaries for Spacetypes for example is actually explicitly querying the OpenStudio Model, which in your case doesn't exist, so a lot of sections wouldn't work (the concept of SpaceType doesn't exist in EnergyPlus...). Worst, because the measure expects the OSM to be loaded successfully, the measure will just crash, period.