Off the top of my head, I see no obvious theoretical reason why a hypothetical Enigma-like rotor machine cipher with publicly known rotor wiring couldn't be secure, even by modern standards. It would presumably need many more rotors and a much more complex stepping scheme than the WWII Enigma had, but that's just engineering detail.
A basic rotor machine cipher can be described mathematically as consisting of two alternating types of layers: the rotor wiring itself, which is an arbitrary (but fixed) invertible map applied to the symbol being encrypted, and the offset between the rotors, which is a simple linear shift of the symbol space that depends on both the key (i.e. the initial rotor positions) and the position of the symbol within the message. That is, mathematically, we can write the encryption process as:
$$ \begin{aligned}
x_0 &= p, \\
x_i &= f_i(x_{i-1} +_A s_{i-1}) \quad\forall i \in \{1,\dots,n\}, \\
c &= x_n +_A s_n,
\end{aligned} $$
where $p$ is the plaintext input symbol, $c$ is the corresponding ciphertext output, $n$ is the number of rotors, $+_A$ denotes addition modulo the cipher alphabet size $A$, the invertible function $f_i: \{0,\dots,A-1\} \to \{0,\dots,A-1\}$ denotes the fixed non-linear permutation of the cipher alphabet applied by the $i$-th rotor wiring, and $s_i = s_i(K,t)$ is the relative offset between the $i$-th rotor and the next one at message position $t$ with the initial key $K$ (with $s_0$ and $s_n$ denoting the absolute offsets of the first and the last rotor respectively).
(Note that the abstract rotor machine described above doesn't even try to include various Enigma-specific features like the reflector or the plugboard, since those are really just tricks for squeezing extra encryption complexity out of the limited number of rotors the Enigma had. With enough rotors, you won't need them.)
Here's a schematic drawing to better illustrate the description above:
Looking at the schematic above, you might note that it looks vaguely similar to various modern block cipher designs, such as a substitution–permutation network like AES. In fact, we can regard the abstract rotor machine described above as a kind of a tweakable block cipher operating on blocks of one symbol, with the wheel wiring $f_i$ acting as an invertible S-box (applied to the whole block at once, so that an explicit P-box is unnecessary) and the key-dependent stepping scheme serving to $s_i$ mix the initial key $K$ and the per-symbol tweak $t$ with the cipher state between each S-box application.
As far as I know, there exists no general attack on the structure described above even if the permutations $f_i$ are publicly known. In fact, if I'm not mistaken, with sufficiently many rotors and a sufficiently complex stepping scheme, the abstract rotor machine described above can in principle compute any permutation of the cipher alphabet even if all the rotor permutations $f_i$ are identical and completely trivial (e.g. swapping a single pair of symbols and leaving everything else unchanged). Thus, it would seem that any attack must necessarily exploit either some weakness in the stepping scheme (or in the number of rotors) and/or the limited size of the cipher alphabet.
For a typical modern block cipher, of course, the alphabet size of a typical Enigma-like rotor machine (corresponding to a block size of about 5 bits) would be utterly insufficient, as an attacker could trivially enumerate the permutation the cipher computes based on just a handful of known ciphertext / plaintext symbol pairs. On the other hand, a mechanical rotor machine with an alphabet size of, say, $2^{64}$ or $2^{128}$ symbols (like in DES or AES) would be utterly impossible to manufacture.
However, to compensate for its small block size, a rotor machine has one major advantage over typical block ciphers: the rotors rotate. Thus, each symbol in any given message is effectively encrypted with a different permutation of the cipher alphabet. With a sufficiently complex stepping scheme, this should effectively scramble the permutation between each encrypted symbol, so that even an attack with access to an encryption oracle will only receive one plaintext/ciphertext symbol pair for each $(K,t)$ pair, and will hopefully have no effective way of correlating these pairs to obtain any useful information about the key (or about past or future messages encrypted using it).
The tricky part, of course, is coming up with such a sufficiently good stepping scheme, especially if you need it to also be simple enough that it could be practically implemented without modern electronics. That's the part that I will leave as an exercise for the reader. :)
